 3-Jan-84 16:18:08-MST,1024;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:18:04-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  24 Dec 83 17:07 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  24 Dec 83 17:04 EST
Date: Sat 24 Dec 83 17:04:05-EST
From: Edward Huang <RMS.G.EH%MIT-OZ@MIT-MC.ARPA>
Subject: NEC/Rainbow MODEM pgms
To: info-cpm@BRL.ARPA
cc: rms.g.eh%MIT-OZ@MIT-MC.ARPA

Hello, I have some members in my RCP/M network who are
hampered due to insufficient info/lack of pub-dom pgms
for the Rainbow 100 (IN 8-BIT MODE, not 16-bit which is easy)
and the NEC PC-8001 (Anyone know how to use its UART?).
I womuld appreciate hearing from others who own the above
machines (running CP/M) and have sucessfully installed MODEM
and/or BYE.         Thanks, --Ed
                         DataTech Network Headquarters
                         415-595-0541 300/1200 baud
ps: Reply DIRECT to me as I am not on INFO-CPM. Thanks
and Happy Holidays!
-------

 3-Jan-84 16:22:12-MST,888;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:22:09-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  25 Dec 83 17:23 EST
Received: From Mit-Ml.ARPA by BRL via smtp;  25 Dec 83 17:15 EST
Date: 25 December 1983 17:18 EST
From: Herb Lin <LIN@mit-ml>
Subject: checksumming program for backing up disks...
To: info-cpm@brl

When I back up my disks, I live in constant fear that I am trashing
a good copy of a file on my backup with a bad copy that somehow
found its way onto the disk that I am backing up.

it seems that a good solution to this would be the checksumming (or
other check) on a disk file that could be compared to a central file
of checksums somewhere.  Anyone know anything like this in 
the public domain or for cheap sale?

tnx.  I will forward responses to the net.

herb lin

 3-Jan-84 16:22:41-MST,1340;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:22:35-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  25 Dec 83 19:58 EST
Date:     Sun, 25 Dec 83 19:53:16 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  MDM7xx overlay for DEC CP/M-80 machines

Bernie Eiben has given us a new overlay for MDM7xx for 3 different DEC
machines that run CP/M-80.  It was announced earlier as a part of the
MDM7xx package available from SIMTEL20 in the MICRO:<CPM.MODEM7>
directory as M7VT-2.ASM, but I felt that additional information might be
of use to Info-Cpm readers.  Here's an excerpt from the message he sent
to me telling what he did.

---forwarded message---

From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>
To: w8sdz at BRL
Subject: MODEM 714

Keith, I modified the VT180 overlay to be "general" in serving VT180 /
Rainbow / DECmate II , the three DEC-micro's currently able to run CP/M
and to "talk" to the outside world.  This overlay supersedes the M7VT-1
one - we have currently three BIOS-versions out in the field - and above
overlay would have necessitated heavy DDTing.  I re-defined EXTCHR to be
closer to KERMIT and redefined IGNORCTL to be able to run HOST-programs
which require Cursor-Control.
 3-Jan-84 16:27:07-MST,1207;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:27:02-MST
Received: From Rand-Relay.ARPA by BRL-VGR via smtp;  27 Dec 83 18:40 EST
Date: 27 Dec 1983 1438-PST
From: Rob-Kling <Kling.UCI-20B@rand-relay>
Return-Path: <KLING%UCI-20b.UCI@Rand-Relay>
Subject: Re: PC Lisp
To: fsbrn@brl-voc, info-micro@brl-vgr, info-cpm@brl-vgr
In-Reply-To: Your message of 27-Dec-83 1329-PST
Received: from UCI-20b by UCI-750a; 27 Dec 83 14:39:41 PST (Tue)
Via:  UCI; 27 Dec 83 14:45-PST




The December 1983 issue of PC Magazine has reviews of two LISPs
for the IBM-PC: IQLISP and mu-LISP-82. 

IQ-LISP:		$175
	Integral Quality
	PO Box 31970
	Seattle, Wash 98103
	206-527-2918

mu-LISP-82		$250
	Microsoft
	10700 Northrup  Way
	Bellvue, Wash 96828
	206-838-8080


Other LISPs for the IBM-PC include:

Intellect-UL:		$225
	PCD Systems Inc.
	163 Main Street	
	Penn Yan, New York 14527
	315-536-7428


Intellect-UL LISP 	$100
	IOTC Inc.
	910 Scully
	Laramie, Wy. 82070
	307-721-5818


LISP/88:		$50
	NORELL Data Systems
	3400 Wilshire Blvd.
	Los Angeles, Ca. 90010


	Rob Kling
	University of California, Irvine
 3-Jan-84 16:29:09-MST,650;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:29:06-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Dec 83 20:03 EST
Date:     Tue, 27 Dec 83 19:56:54 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Micro@brl-vgr, Info-Cpm@brl-vgr
Subject:  Need init info for MITS SIO board

A friend wants to initialize his old MITS SIO S-100 board for either
300 baud or 1200 baud taking advantage of the fact that it can be
programmed to use X1 or X16 division of the system clock.  He doesn't
have a book and needs to know what to output to the board to do this.
 3-Jan-84 18:34:53-MST,1651;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 18:34:41-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Dec 83 14:13 EST
Date:     Wed, 28 Dec 83 14:08:50 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  MDM7xx overlay warning

Anyone who upgrades to MDM715 should be told that the patching
instructions in all the overlays are based upon the smaller
MDM712-713-714 programs.  Thanks to Bernie Eiben at DEC for pointing
this out and telling about a simple way to calculate the number of pages
to save.

--- forwarded message ---

Date: 28 Dec 1983 1214-EST
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>
To: w8sdz at BRL
Subject: MODEM-Overlays

Since MODEM has "grown" again, it might be usefull to update the "SAVE
66 MODEM.COM" to something like "SAVE 68 MODEM.COM" -- one otherwise
gets quite erratic behaviour... A "better" way would probably a short
explanation of the "magic":

To convert the HEX "NEXT" address printed by DDT or SID into the decimal
number You must give to the SAVE command in order to save the customized
MODEM-version to disk, use the following algorithm: first take the
leftmost two hex-digits and compute their decimal equivalent (e.g. 3C80
yields 3C, which is 60 decimal). Then, subtract 1 from that ONLY IF the
rightmost two digits are 00 (for example the 60 above would remain 60
because the rightmost two digits of 3C80 are 80, not 00 ). The final
value is the number to give to SAVE.	[Courtesy of BDS C Users-Guide,
Leor Zolman].

--- end of forwarded message ---
 3-Jan-84 18:39:25-MST,630;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 18:39:21-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Dec 83 23:28 EST
Date:     Wed, 28 Dec 83 22:06:23 EST
From:     Rick Conn <rconn@brl>
To:       hplabs!hao!seismo!rlgvax!cvl!umcp-cs!aplvax!ded@ucb-vax
cc:       info-cpm@brl
Subject:  Re:  Determining free disk space

The DFREE routine in SYSLIB determines free disk space for a CP/M 2.2
system.  It is a simple subroutine in assembly language, and you can get
the source (make sure it is for SYSLIB 2.7) from SIMTEL20 or SIG/M.

Rick
 3-Jan-84 18:50:19-MST,554;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 18:50:15-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Dec 83 23:28 EST
Date:     Wed, 28 Dec 83 22:12:24 EST
From:     Rick Conn <rconn@brl>
To:       Keith Petersen <W8SDZ@simtel20>
cc:       Info-Cpm@brl-vgr
Subject:  Re:  LRUN files

There is also LRUNZ in the ZCPR2 set.  This is a version of LRUN which
can be used as an extended command processor under ZCPR2 and has a built-in
search for the LBR file.

Rick
 4-Jan-84 09:11:25-MST,1079;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:11:19-MST
Received: From Stl-Host1.ARPA by BRL-VGR via smtp;  28 Dec 83 23:27 EST
Date: 28 Dec 1983  22:25 CST (Wed)
Message-ID: <WANCHO.11979242740.BABYL@STL-HOST1>
From: WANCHO@stl-host1
To:   INFO-CPM@brl-vgr
Subject: Need Help with CCS 2422 FDC

As thorough as the manuals for the CCS 2422 FDC appear to be, it
doesn't help me configure the board precisely the way I need it.  What
I need is to set it up so that it uses NO memory address space, banked
or otherwise, and does not Auto Boot or anything.  I simply want it to
sit there, waiting to be "addressed" with something equivalent to an
attached BIOS.

The configuration is for a N* HORIZON running TurboDOS, and, yes, I
have the alternate U22 addressed at F8H-FDH (instead of the default
30H-34H and 04H).  I have also read the article in Microsystems, but
it was no help for this case.

If anybody has made such a configuration work, please contact me by
net mail.

Thanks,
Frank
 4-Jan-84 09:25:13-MST,786;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:25:09-MST
Received: From Brl-Bmd.ARPA by BRL-VGR via smtp;  2 Jan 84 13:07 EST
Date:     Mon, 2 Jan 84 12:52:31 EST
From:     Keith Petersen <w8sdz@brl-bmd>
To:       Info-Modem7@mit-mc, Info-Cpm@brl-vgr
Subject:  Incorrect phone number in MDM715 overlay

The following is forwarded from the Sysop Clearinghouse RCPM:
---
Date: 12/31/83
From: Walt Jung
To:   All
Re:   MDM715 numbers

A bad phone number has crept into MDM715, in the NM overlay, under my
name. The correct number is 301-661-2175.. pls correct the copy for
distribution, so that the poor soul doesn't get called to death.  Why
doesn't RCPM-nnn.LST get checked for these numbers?

--end--
 4-Jan-84 09:26:37-MST,898;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:26:33-MST
Received: From Brl-Bmd.ARPA by BRL-VGR via smtp;  2 Jan 84 13:33 EST
Date:     Mon, 2 Jan 84 13:30:28 EST
From:     Keith Petersen <w8sdz@brl-bmd>
To:       Info-Modem7@mit-mc, Info-Cpm@brl-vgr
Subject:  Using MDM716 with Cromemco CDOS

CDOS users: Get M7CD-1.ASM from the SIMTEL20 MICRO:<CPM.MODEM7>
directory.  After you overlay MDM716.COM using DEBUG, patch the
following locations to NOPs (binary zeros): 2ABD, 2ABE, 2ABF, 2AC0.
This will disable the CP/M disk stat call function 1Fh which is
not implemented in the current version of CDOS.  The MDM716 DIR
function will then work, but will show 0k left on the disk.
That's livable, and certainly better than before when CDOS gave
an error message and jumped out of MDM716 to return to the system.
--Keith
 4-Jan-84 09:51:15-MST,593;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:51:12-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:19 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  29 Dec 83 22:50 EST
Date: 29 December 1983 22:50 EST
From: Robert L. Plouffe <PLOUFF@mit-mc>
To: INFO-CPM@mit-mc, INFO-MODEM7@mit-mc
cc: PLOUFF@mit-mc

Regarding release of mdm716 per Keith's message, and for
those at MIT-MC who can't ftp from SIMTEL20.  please be
advised that the squeezed source file is also at MC in
MC:FJW;MDM716 AQM

 4-Jan-84 09:56:37-MST,4950;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:56:25-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:18 EST
Date:     Thu, 29 Dec 83 13:46:28 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
cc:       Info-Modem7@mit-mc
Subject:  MDM716 release - a major improvement

Bob Plouffe has just released MDM716, a major improvement in the
MDM7xx series of MODEM7 programs.  It's now available on SIMTEL20
in the MICRO:<CPM.MODEM7> directory as:

   MDM716.ASM - the source code (not normally needed, use .COM and overlay)
   MDM716.AQM - same as above, but squeezed, stored in ITS-Binary format
   MDM716.COM - stored in ITS-Binary format
   MDM716.HEX - for people who cannot FTP .COM files

NOTE: When customizing the .COM file with your overlay, use the command
      SAVE 69 MODEM7.COM after exiting DDT.  This is because MDM716.COM
      is larger than MDM712-713-714 for which the instructions were written.

Here's what's new in this, and a few previous versions:

----

12/27/83  1. Detection of first SOH is made less susceptible to
          noise hits on the line and to extraneous characters sent
          by a remote just prior to sending sector header. (such
MDM716    as when 'Q' option is not set at remote under 'BYE')

          2. Permits operation with a remote computer using `BYE'
          and any version of the CHRISTENSEN PROTOCOL without
          the need to set the 'Q' option at remote when receiving
          files FROM it (SENDING & RECEIVING WHEN BOTH ENDS ARE
          CHANGED TO THIS CODE).  Thus progress reporting
          at both ends is possible. This works in both single
          file and BATCH modes of operation.

          3. At the receive file end, progress is shown only after
          each sector is actually received rather than when it is
          awaiting a sector.  Thus, the sector count at the end of
          receiving a file matches the actual sector count in the
          file.

          4. Adds back the feature previously deleted that allows
          the operator the option of retry if the ERROR LIMIT is
          reached.  This is virtually essential on packet switched
          Networks like ARPANET and others that can get throttled
          by traffic and delay the sending of packets.  Who needs
          an automatic ABORT after receiving 1120 sectors out of
          1250 when a retry would probably allow continuance?

          5. Corrects the SENDFILE routines that caused some of the
          problems that the above fixes now tolerate.  File name
          characters were actually sent twice.  Once as found in the
          FCB (in FCB format) and again in CP/M format - one after
          the other, character-by-character including the '.' of the
          CP/M format.  Whoo boy, what a mess.  Anyway the program
          is now fixed not to do that and the receive-file changes
          tolerate both the new and the old. 

          6. Provides noise and extraneous string protection to the
          detection of 'ACK' and 'NAK'.  RESENDS A SECTOR ONLY ON
          RECEIPT OF A VALID NAK OR AFTER A TIMEOUT ERROR MSG.

          7.  Fixed T-MODE so that re-use of the command buffer
          does not cause a problem. T-MODE now uses 128 bytes from
          CMDBUF+2 so that buffer size is not wiped out.      

          8.  Corrected MENU2 for the (V)iew option to show the
          use of 'R' and/or 'S' to view Received and/or Sent bytes
          at the console.  This feature present since MODEM2 but
          never correctly shown in the MODEM7 help screens.

          9.  Fixed buffer problem that caused batch mode to
          fail unpredictably when sending a large number of files.
       
                                               - Bob Plouffe

12/11/83  Expanded Hayes redial options. Eliminated scrolling
 MDM715   of CRT display during redial. Added clue to abort CAL.
          Eliminated duplicate 'CONNECT' msg on CRT (from Hayes).
          Eliminated display of ALT LD access codes. Faster redial
          for Hayes. Resets Hayes (ATZ) on BYE command. Finished
          clean-up of comments missed by NEAT. Shortened 3 LTR
          command help screen by one line. New NUMLIB ORG 0D00.
                                      - Tom Bering

11/11/83  Releasing full source code, including all comments.  Updated
 MDM714   the telephone library for currently available RCPM systems.
          LF not automatically added in "L" half duplex mode now.  Can
          be added via "TLF" command if needed.  Renamed the overlays
          to allow them to remain independent of further updates.  Ex-
          ample:  M7AP-1.ASM, M7GP-1.ASM, M7PC-1.ASM, etc.  Enjoy.
                                      - Irv Hoff

--end--
 4-Jan-84 10:31:08-MST,1437;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 10:30:59-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:22 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  30 Dec 83 2:30 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 29 Dec 83 23:25-PST
Date: 27 Dec 83 10:16:00-PST (Tue)
To: info-cpm@brl
From: hplabs!hpda!fortune!burton@ucb-vax
Subject: How Does Wordstar Work - the 'r' command.
Article-I.D.: fortune.2106

How does the 'r' command work in Wordstar V3.x?

Why can't a cpm 'submit' work properly.  Does WS do its own submit.  If so,
it doesn't leave behind a $$$.sub file, if my system is rebooted before the
return from the cp/m command back to WS.

Is the 's' spelstar command just a special purpose 'r' command?  Could Spelstar
be operated from the 'r' command?  

Could WS be patched by replacing SPELSTAROVR (about location 1000h) with DU
to any command name, and get that command run off the 's' command?

Is all of WS.COM cleared out of RAM when an 'r' command (or SPELSTAR) is
invoked?

Also, my version of XDIR3 (1.5) running on straight vanilla cp/m doesn't work
properly when run from 'r'.

-- 
>From phipps Wed Dec 21 18:05:03 1983
To: burton

   {allegra,amd70,cbosgd,dsd,floyd,harpo,hollywood,hpda,ihnp4,
    magic,megatest,nsc,oliveb,sri-unix,twg,varian,VisiA,wdl1}
   !fortune!phipps
 4-Jan-84 10:57:49-MST,825;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 10:57:46-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:22 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  30 Dec 83 3:30 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 30 Dec 83 0:26-PST
Date: 21 Dec 83 6:27:04-PST (Wed)
To: info-cpm@brl
From: decvax!duke!mcnc!ecsvax!emigh@ucb-vax
Subject: Latest version of UC.C (UNIX to CP/M file transfer shell)
Article-I.D.: ecsvax.1739

I have posted the latest version of UC.C (UNIX(tm) to CP/M file transfer
shell) to net.sources (ecsvax.1738).  The program was written by Rick
Conn (rconn@brl), and the latest version corrects a minor error in that
UC always created a uc.log file, even when the option was turned off.
 5-Jan-84 09:23:19-MST,689;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:23:14-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  6 Jan 84 10:17 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:31 EST
Received: From Bnl.ARPA by BRL via smtp;  30 Dec 83 11:03 EST
Date: 29-Dec-83 21:07:48-EST
From: jalbers@bnl
Subject: BYE for CPM3?
To: info-cpm@brl



	Does anyone out there have BYEx.x out for the Osborne
Executive 1 running CPM3?  Does anyone have a version for CPM3?
Could anyone help someone write/set-up/whatever such a version?


				(Help! Help!)

				Jon Albers
				(jalbers@bnl or ALBERS@ML)

 5-Jan-84 09:23:40-MST,2319;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:23:33-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  6 Jan 84 10:17 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:32 EST
Date:     Fri, 30 Dec 83 13:27:15 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  New Apple CP/M overlay for MDM7xx

M7AP-2.ASM, an updated Apple CP/M overlay for MDM7xx, is now available
on SIMTEL20 in the MICRO:<CPM.MODEM7> directory.

This overlay file enables Apple II computers with the Apple Super
Serial card and external modem to use the MDM7xx phone modem program.
It also supports the following Apple modem configurations:

      a) CCS 7710 serial interface and external modem
      b) SSM serial interface and external modem
      c) Apple communications interface and external modem
      d) Mountain Hardware CPS Multifunction card and external modem
      e) Prometheus Versacard with software baud select and ext. modem

To use SET with the Prometheus Versacard a small hardware mod must be
made, since the Versacard only supports baud rate selection via DIP 
switches. This Mod will allow the Versacard to be switched between
300 and 1200 baud via software.

Revision history:

12/26/83 - Added Versacard support with               
           software baud selection. Revised        
           to allow easy serial card relocation
           made SYSVER more informative.      - Tony Antonucci
11/11/83 - Renamed to M7AP-1.ASM, no changes  - Irv Hoff
10/07/83 - Added CPS card support             - Wally Hubbard
07/27/83 - Renamed to work with MDM712        - Irv Hoff
07/01/83 - Revised to work with MDM711        - Irv Hoff
06/22/83 - Revised to work with MDM710        - Irv Hoff
05/27/83 - Updated to work with MDM709        - Irv Hoff
05/15/83 - Revised to work with MDM708        - Irv Hoff
04/11/83 - Updated to work with MDM707        - Irv Hoff
04/04/83 - Updated to work with MDM706        - Irv Hoff
02/27/83 - Updated to work with MDM705        - Irv Hoff
02/12/83 - Used MDM703CF to make this file
           for Apple computers using a var-
           iety of serial interface cards
           with external modem.               - Bruce Kargol
 5-Jan-84 09:28:03-MST,2082;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:27:54-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  6 Jan 84 10:18 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:32 EST
Date:     Fri, 30 Dec 83 13:29:50 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  ERAQ15.ASM now available

ERAQ15.ASM is now available on SIMTEL20 in the MICRO:<CPM.DIRUTL>
directory.

ERAQ15 is a selective erase program.  Shows file names and separately
asks confirmation on each, prior to erasure.  This minimizes accidental
erasures.  (If you still erase a file you meant to keep you can easily
restore it to normal by using a program called "UNERA".  This assumes
you have not overwritten any part of it).  This program is patterned
after the ERAQ function provided with Digital Research's MP/M system.

Modification & Update List:

12/21/83  Increased capacity to more than 256 files.  Used to have 
  v1.5    problems with large directories because file counters were
          only eight bits wide - now 16.  Made the "no files specified"
          error optional by conditional assembly.  Added "ASEG" directive
          and eliminated colons on equate lables to allow assembly by
          Macro-80.
                          Tony Newman (WB7FCN)

01/10/83  Modified to eliminate warm reboot when finished.  Was most
          annoying, for if not in 'A' drive rebooted both the current
  v1.4    drive and 'A' as well.  Reformatted, now assembles normally
          with ASM or MAC.  Standardized tab stops, some were missing.
          Included error message if no files specified for erasure.
                                      - Irv Hoff

04/16/82  Mask bit 7 for console output for memory-mapped video boards
          which use the high bit for attribute info.

12/10/81  Added checks for $SYS and $RO attributes.

11/20/81  Added default to '*.*' if no input parameters.

11/08/81  Original program written by Thomas Hill.
 5-Jan-84 09:28:36-MST,3094;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:28:27-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  6 Jan 84 10:18 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:32 EST
Date:     Fri, 30 Dec 83 13:28:40 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  BYE3-16.ASM now available

BYE3-16.ASM is now available on SIMTEL20 in the MICRO:<CPM.BYE3> directory.
This program allows modem callers to use a CP/M system just as if
they were seated at the system console.  Special assembly-time options
allow limiting the caller's access by password and/or access to only a
message-service program.  A number of external routines are available
to adapt this program to various computers.
         
This revision corrects some problems with conditional assembly errors.
Here's an excerpt from the update history:

12/16/83 Cleaned up some conditional statements.  Added WELFILE
 v3.1.6  conditional statement to bypass typing Welcome.  Made
         minor mods to the SMODEM routine to make it work on a
         KAYPRO.  - Bill Duerr

12/15/83 Included a new Smartmodem routine.  This will be needed by
 v3.1.5  most users since the Smartmodem (or similar, such as the U.S.
         Robotics) are in common use.  (There were four different rou-
         tines being used in the various external inserts.  This will
         standardize that to just one version.)  Hopefully this routine
         will prevent reception of any incoming call until it is ready
         for the call.  (Steve Holtzclaw's extensive Smartmodem routine
         which checks echo characters may still be required under some
         cirumstances.  It is not needed with the US Robotics modems.)
         This version has been tested extensively on several RCPM sys-
         systems using several different types of computers, including
         2651, 2661, 2850 and 2851 I/O devices..
                      - Irv Hoff and John Ferguson

BYE3 supports the following modems and/or USART combinations:

SMDM routine   - by Steve Holtzclaw   B3SM51-3.ASM (includes 8251 I/O)
8250           - by Paul Traina       B3HZ89-3.ASM
2651           - by Paul Traina       B3COMP-3.ASM
8251+CTC timer - by Irv Hoff          B3DATA-3.ASM
APPLE-CAT      - by Dave Roznar       B3ACAT-3.ASM
MM100          - by Dave Jaffe        B3DCH-3.ASM
HZ-100         - by John Ferguson     B3HZ10-3.ASM
Kaypro         - by Steve Sanders     B3KPRO-3.ASM
MMII (Apple)   - by Paul Traina       B3MMII-3.ASM
PMMI           - by Ward Christensen  B3PMMI-3.ASM
SIO            - by Steve Fox         B3SIO-3.ASM
Televideo 802  - by K. Robesky        B3T802-3.ASM

Most users of this program will have an auto-answer modem such
as the Hayes 300 or 1200, the U.S.Robotics or Rixon.  A routine
that supports these modems has been included.  Set the SMODEM
equate to 'YES' if you have one of these modems, 'NO' if another
type of auto-answer modem such as the PMMI, Bell 212A, etc.
 5-Jan-84 09:30:38-MST,1240;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:30:34-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  6 Jan 84 10:18 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Jan 84 15:32 EST
Date:     Fri, 30 Dec 83 13:36:18 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  UC.C under 4.2BSD Unix


----- Forwarded message # 1:

Date:     Fri, 30 Dec 83 8:53:17 EST
From:     Rick Conn <rconn@brl>
To:       Richard Kawala <kawala%ucbcory@ucb-vax>
cc:       w8sdz@brl, rconn@brl
Subject:  Re:  uc.c

UC.C was written for and is supported on UNIX SYSTEM V.  Two problems
with it have been reported to me via USENET contacts when one tries
to run it on 4.2BSD, but without a 4.2BSD machine available with direct-
connect, I am not supporting 4.2BSD implementations.

One problem is with the stat() routine in UC.  Its name should be changed
due to a conflict with some library routine under 4.2BSD.

The other problem is with the interrupt scheme used.  My reports hinted
that a longjump() was required under 4.2BSD.  I have no other details.

Hope this helps.

	Rick Conn

----- End of forwarded messages
 6-Jan-84 08:53:32-MST,806;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 08:53:27-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  5 Jan 84 12:27 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Jan 84 8:40 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  5 Jan 84 8:22 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jan 84 4:56-PST
Date: 24 Dec 83 19:42:52-PST (Sat)
To: info-cpm@brl
From: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax
Subject: Re: The response on BIOS's I promised. - (nf)
Article-I.D.: uiucdcs.4700

#R:sri-arpa:-1465200:uokvax:7900004:000:110
uokvax!andree    Dec 22 17:13:00 1983

Could you post more details on your BIOS for the Ithaca hardware?
Or maybe post a copy to net.sources?

	<mike
 6-Jan-84 08:54:24-MST,1083;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 08:54:19-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  5 Jan 84 12:31 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Jan 84 8:45 EST
Received: From Brl-Voc.ARPA by BRL via smtp;  5 Jan 84 8:34 EST
Date:     Thu, 5 Jan 84 8:17:01 EST
From:     "Ferd Brundick (LTTB)" <fsbrn@brl-voc>
To:       Mike Simpson <msimpson@bbn-unix>
cc:       northstar-users@simtel20, info-micro@brl, info-cpm@brl, msimpson@bbn-unix
Subject:  Re:  printer questions

Hi,

You want to install patches in the user-defined functions ^Q,^W,^E, and ^R.
These can be multiple key sequences, which is quite handy if your printer
uses ESCape sequences like mine does.  Check your Word* manual on how to go
about defining your own functions.

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>
 6-Jan-84 09:01:34-MST,2257;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 09:01:27-MST
Received: From Nbs-Sdc.ARPA by BRL-VGR via smtp;  5 Jan 84 14:08 EST
Date: Thu, 05 Jan 84 14:09:44 EST
From: blue@nbs-sdc
Subject: Conference Announcement
To: info-micro@brl-vgr
Cc: info-cpm@brl-vgr

        Numerical Computation and Mathematical Software 
                    For Microcomputers

    On March 19-21, the ACM Special Interest Group on Numerical
Mathematics (SIGNUM) will sponsor a conference on Numerical
Computation and Mathematical Software For Microcomputers. The
conference will be held at the Hilton Harvest House Hotel in Boulder,
Colorado. Registration will be limited to approximately 250
applicants. 

                    Invited Papers

    Invited speakers include P. W. Gaffney (Oak Ridge), "FORTRAN
Compilers for Microcomputers;" W. M. Gentleman (National Research
Council), "MIMD Architecture using Microcomputers;" G. A. Hamlin (Los
Alamos), "Graphics on Microcomputers;" J. Siebenaler (Motorola),
"Strategy and Testing of Floating-Point Coprocessors;" R. F. Sincovec
(U. Colorado, Colorado Springs), "Using Modula-2 and Ada for
Numerical Computations on Microcomputers;" and J. Wooten (Los
Alamos), "Use of Microcomputers in a Scientific and Engineering
Workstation Environment." 

                    Special Sessions

    There will be special sessions of 30-minute talks on
Microcomputers in Parallel Architectures and on Mathematical Software
for Microcomputers.


                    Vendor Exhibits

    There will be an exhibit of computers and software during the
meeting. Vendors will make 30-minute oral presentations during
special evening sessions.

                    Contributed Papers

    One-page astracts for 20-minute contributed talks should be
submitted immediately to:

        Dr. William G. Pool, Jr.
        Pacific Analysis & Computing
        1020 109th Avenue SE
        Bellevue, Washington 98004

                    Registration

    For information, contact:

        Dr. Roland A. Sweet
        MS 713 National Bureau of Standards
        325 Broadway
        Boulder, Colorado 80303
        (303) 497-5671
 6-Jan-84 09:27:05-MST,937;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 09:26:59-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  5 Jan 84 12:24 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Jan 84 7:24 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  5 Jan 84 7:14 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jan 84 4:09-PST
Date: 4 Jan 84 14:40:47-PST (Wed)
To: info-cpm@brl
From: ihnp4!ihuxe!staley@ucb-vax
Subject: FOR SALE CP/M SYSTEM
Article-I.D.: ihuxe.463

S-100(10 slot),Internal Power Supply,Fan'd inclosure,many cut-outs for 
connectors,RS-232 Terminal & Modem Interfaces,Z80-CPU,64k Ram,Tarbell Disk
Controller,2-serial,2-parallel I/O ports,2-8inch Disk Drives in fan'd inclosure
with power supply,Cabling,Documentation,CP/M,Televideo 912c Terminal,Misc 
Software $1700 
					ihuxe!staley
					1-312-979-1646
					1-312-462-1029
 6-Jan-84 09:27:28-MST,1268;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 09:27:23-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  5 Jan 84 12:29 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Jan 84 8:40 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  5 Jan 84 8:24 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jan 84 5:08-PST
Date: 24 Dec 83 19:43:04-PST (Sat)
To: info-cpm@brl
From: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax
Subject: Re: UC 1.4 - (nf)
Article-I.D.: uiucdcs.4701

#R:sri-arpa:-1469500:uokvax:7900005:000:592
uokvax!andree    Dec 22 17:19:00 1983

I'm running uc under 4.1c No problems once I got it up.

There was a problem in bringing it up. Uc gets file stats through
a function called `fstat', which can be found near the end of the
source. Fstat is also a library routine on 4.1c, and is called
by both printf and stat. Since the uc fstat calls stat, calling
printf leads to an infinite recursion. The first thing uc does
is print it's name out, so running it produces a short delay,
followed by dropping core due to stack overflow. I changed the
name of the routine from fstat to filestat, and everything worked
like a charm.

	<mike
 6-Jan-84 10:26:56-MST,1015;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 10:26:52-MST
Received: From Brl-Vgr.ARPA by BRL-TGR via smtp;  5 Jan 84 12:33 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Jan 84 8:59 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  5 Jan 84 8:46 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jan 84 5:39-PST
Date: 30 Dec 83 19:45:03-PST (Fri)
To: info-cpm@brl
From: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax
Subject: UDS 212 A/D autodial code wanted - (nf)
Article-I.D.: uiucdcs.4734

#N:uokvax:7900006:000:340
uokvax!andree    Dec 28 01:51:00 1983

I am working on autodial code (using YAM) for a UDS 212 A/D.  This modem
tends to output lines like `OFF HOOK - D.T. - DIALING - ABT - COMPLETE'.
The problem is that there is NO way to turn this off. If anyone has code
(C preferable) to handle this modem, or something similiar, I'd appreciate
seeing a copy before I start.

	Thanx,
	<mike
10-Jan-84 10:55:56-MST,552;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 10:55:52-MST
Received: From Parc-Maxc.ARPA by BRL-VGR via smtp;  5 Jan 84 13:24 EST
Date: Thu, 5 Jan 84 10:18 PST
From: BillHolland.es@PARC-MAXC.ARPA
Subject: Re: BYE3-16.ASM now available
In-reply-to: "w8sdz@brl.ARPA's message of Fri, 30 Dec 83 13:28:40 EST"
To: Keith Petersen <w8sdz@brl.ARPA>
cc: Info-Cpm@brl-vgr.ARPA

HEY CAN I GET THERE FROM A ALTO ? HOW ABOUT MY SYSTEM AT HOME ? PLEASE
GIVE DETAILS.....BIG DUMMY

Bill

10-Jan-84 10:56:58-MST,740;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 10:56:52-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Jan 84 20:30 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  5 Jan 84 20:20 EST
Date: 5 January 1984 20:21 EST
From: Eric Stork <STORK@mit-mc>
Subject: stork
To: info-cpm@brl

Subject: dBASE2 question
 
Can someone tell me how to set up DBASE2.COM so that it can be permanently
on Disk C:, and will find its overlay files on C: even if it is
invoked from A: or B:?
 
In WordStar there is a location to set for where to look for
overlay files.  Logically, there should be such a location in dBASE, too.
Advice will be appreciated.
 
Eric.

10-Jan-84 10:57:43-MST,739;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 10:57:38-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Jan 84 20:30 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  5 Jan 84 20:24 EST
Date: 5 January 1984 20:25 EST
From: Eric Stork <STORK@mit-mc>
To: info-cpm@brl
cc: STORK@mit-mc

Subject: dBASE2 question

Can someone tell me how to set up DBASE2.COM so that it can be permanently
on Disk C:, and will find its overlay files on C: even if it is
invoked from A: or B:?

In WordStar there is a location to set for where to look for
overlay files.  Logically, there should be such a location in dBASE, too.
Advice will be appreciated.

Eric.

10-Jan-84 11:04:16-MST,1110;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:04:10-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  6 Jan 84 9:39 EST
Date:     Fri, 6 Jan 84 9:28:54 EST
From:     David Towson (CSD) <towson@amsaa>
To:       info-cpm@brl-vgr, info-micro@brl-vgr
Subject:  How to use a TAC.

During 1983, there was considerable discussion (and confusion) in these
newsgroups concerning the mysteries of the Terminal Access Controller (TAC),
that frustrating device by which one can access the Defense Digital Network
of computers.  Soon, passwords will be required for TAC access, so
this message will not be of interest to all.  However, for those in a position
to benefit, the TAC Users Guide can be obtained by anonymous FTP from
machine usc-isia.  Login with username anonymous and password ftp (or any 
non-null string), and ask for file <documentation>tac-user-guide.  You might
also like to get a directory listing for the <documentation> directory, which
is quite large, and which has many goodies.


Dave Towson
towson@amsaa

10-Jan-84 11:04:29-MST,741;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:04:25-MST
Date:     Fri, 6 Jan 84 11:25:43 EST
From:     Dave Towson (info-cpm) <cpmlist@brl-vgr>
To:       info-cpm@brl-vgr
Subject:  [STERNLIGHT%USC-:  BYE with TRS-80 Models 2/12/16 (Part 2).]


----- Forwarded message # 1:

Received: From Usc-Ecl.ARPA by BRL-VGR via smtp;  5 Jan 84 17:11 EST
Date:  5 Jan 1984 1210-PST
From: STERNLIGHT%USC-ECL@SRI-NIC
Subject: BYE with TRS-80 Models 2/12/16 (Part 2).
To:   info-cpm-request at BRL-VGR
cc:   sternlight at ECL

By the way, you need to include B3SIO-3.ASM
in BYE3-16 to have it work with the 2/12/16s.  -david--
-------

----- End of forwarded messages
10-Jan-84 11:06:25-MST,1903;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:06:19-MST
Date:     Fri, 6 Jan 84 11:24:08 EST
From:     Dave Towson (info-cpm) <cpmlist@brl-vgr>
To:       info-cpm@brl-vgr
Subject:  [STERNLIGHT%USC-:  Running BYE on TRS-80 Models 2/12/16]


----- Forwarded message # 1:

Received: From Usc-Ecl.ARPA by BRL-VGR via smtp;  5 Jan 84 17:10 EST
Date:  5 Jan 1984 1206-PST
From: STERNLIGHT%USC-ECL@SRI-NIC
Subject: Running BYE on TRS-80 Models 2/12/16
To:   info-cpm-request at BRL-VGR
cc:   sternlight at ECL

Well, users of the TRS-80 Models 2, 12 and 16 running CP/M can
finally set up bulletin boards using bye.  The latest version,
bye3-16 will run fine above bdos.  Set BYELOW to 'NO',
reconfigure cp/m to leave enough space in high
memory, and you're off.  For Pickles and Trout CP/M, version 2.2m,
what works is to set the top of CP/M to EFFF using the menu configuration
program.  If you're using a Smartmodem, set the base address of
the ports to F4 for Serial Port A or F6 for serial port B.
I haven't figured out how to handle the baud rate port yet but
if you use the MENU setup command in P&T, you can set that port
for either 300 or 1200 baud and leave it there.  Make sure
you rename bye, since users need to log off by hanging up, not
by typing bye and invoking the bye program (it hangs).  You can
create a substitute program named 'bye' if you like, which simply
types 'please hang up now' over and over when it is invoked.
If anyone figures out how to get the baud rate select features
working in bye3 with P&T CP/M, please let me know.
Note also that BYELOW set to YES won't work for P&T CP/M; the
bye program runs fine until it tries to drop into CP/M,
but then it hangs.  If anyone has solved that one also, please let
me know.
--david--
-------

----- End of forwarded messages
10-Jan-84 11:09:50-MST,1630;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:09:42-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  6 Jan 84 16:20 EST
Date:     Fri, 6 Jan 84 16:17:32 EST
From:     David Towson (CSD) <towson@amsaa>
To:       info-cpm@brl-vgr, info-micro@brl-vgr
Subject:  "How to use a TAC" - correction!

OOPS!!!  It seems I goofed; that file name has a .doc on the end.  It should
read "<documentation>tac-user-guide.doc".  Sorry!

Dave


----- Forwarded message # 1:

Received: From Brl-Vgr.ARPA by AMSAA via smtp;  6 Jan 84 9:46 EST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  6 Jan 84 9:39 EST
Date:     Fri, 6 Jan 84 9:28:54 EST
From:     David Towson (CSD) <towson@amsaa>
To:       info-cpm@brl-vgr, info-micro@brl-vgr
Subject:  How to use a TAC.

During 1983, there was considerable discussion (and confusion) in these
newsgroups concerning the mysteries of the Terminal Access Controller (TAC),
that frustrating device by which one can access the Defense Digital Network
of computers.  Soon, passwords will be required for TAC access, so
this message will not be of interest to all.  However, for those in a position
to benefit, the TAC Users Guide can be obtained by anonymous FTP from
machine usc-isia.  Login with username anonymous and password ftp (or any 
non-null string), and ask for file <documentation>tac-user-guide.  You might
also like to get a directory listing for the <documentation> directory, which
is quite large, and which has many goodies.


Dave Towson
towson@amsaa


----- End of forwarded messages
10-Jan-84 11:34:35-MST,832;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:34:31-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Jan 84 4:05 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  7 Jan 84 3:56 EST
Date: 7 January 1984 03:54 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Church Support Software Distribution
To: ABN.ISCAMS@usc-isid
cc: INFO-CPM@brl
In-reply-to: Msg of 17 Oct 1983 10:00-PDT from ABN.ISCAMS at usc-isid

If you can get a disk of your Church Support software to me by
US Snail, Workman would be willing to distribute at what amounts
to his cost (somewhere between 20 and 30 bucks depending on a
number of factors) largely for good will.  He's got a number of
churches within his customer base and they're always asking for
help.

10-Jan-84 11:47:38-MST,800;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:47:34-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Jan 84 8:53 EST
Date:     Sat, 7 Jan 84 8:27:43 EST
From:     Rick Conn <rconn@brl>
To:       Eric Stork <STORK@mit-mc>
cc:       info-cpm@brl
Subject:  Re:  stork

Eric,

	I've had a similar need, but never found a solution.  Instead,
I got around it under ZCPR2 by creating a script command like the
following:

		A:;dbase setup;B:

	In this way, I have all my work on B: and dbase.com and its
overlays on A:.  The command processor goes to A:, runs dbase, and the
setup.prg file sets default to B:, so any files I reference come from B:.
When done, the trailing B: puts me back into B:.

		Rick
10-Jan-84 12:10:58-MST,4092;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 12:10:47-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Jan 84 15:40 EST
Date:     Sat, 7 Jan 84 15:35:13 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  dBASE2'S RESET function

Thanks to Eric Stork for the following tip for users of DBASE2:

---
Subject: dBASE2's RESET function
 
dBASE2's  RESET  function  does  not work as it should.  That can be a
serious problem.  But there is a fix.  A bit tricky, but it works.  It
took so long to figure it out that it seems worthwhile  to  send  this
note to the net to share the fix.
 
Over  the  holidays,  I  spent  some time (quite a bit, it turned out)
helping  a  doctor  friend  of  mine  fix  his  accounting  system  by
interfacing it to dBASE2.
 
His application requires several disk changes.  We duly inserted RESET
commands in the proper places, but the thing still would not  work  --
every  effort  to  write to a changed disk bombed out with 'BDOS Error
R/O'
 
After a lot of study in various references from  magazines,  etc.,  we
finally  realized why -- RESET simply does not reset the CP/M disk map
in memory, as it should.  No way to make it work, either, by using SET
DEFAULT or so.
 
The solution is in an unpublicized feature of dBASE2 that permits  the
user  the  write  his  own  assembly language routines, POKE them into
memory above dBASE2's code, CALL them and  RETURN  from  them.   Above
dBASE2's  memory  means  above  A400h,  which is used only for sorting
dBASE files.
 
The routine that finally did the trick was placed into a  file  called
RESETT.CMD (two t's to differentiate from dBASE2's RESET command).  We
then inserted in the main command file the line:
                                                 DO   RESETT 
after every disk swap (we always swapped on B:)
 
           * This command file is RESETT.CMD
           SET CONS OFF
           STORE 49152 to I
           POKE I,0,17,2,0,14,37,205,5,0,201
           * above line resets ONLY Drive B:
           SET CALL TO I
           CALL I
           SET CONS ON
           ?  "SOFT Warm Boot on B:"+CHR(7)
           RETURN
 
Explanations (of non-obvious lines, only):
          STORE 49152 TO I   means variable I=C000h
                             (dBASE2 reqires all decimals)
 
          POKE I,x,v,v,v,v,v,v,v,v,v     (v=decimal value)
 
                             The 'I' is the address at which
                              the POKE is to store the following data.
 
                             The 'x' can  be  any  value.   After  the CALL,
                              HL will point to a memory byte that will
                              contain whatever value is in the 'x'
                              position  (could be length of string, if
                              that is useful)
 
                             The v,v,v,v are whatever routine you want
                              to execute.  After the CALL, the
                              Program Counter is set to the first 'v'.
                              The last 'v' must be a RETURN to your
                              dBASE2 command file
 
            In the illustration:
                             17D = 11H = LXI D
                             2,0 = 02h = 0000$0000$0000$0010B
                                            (to reset Drive B:)
                             14D = 0EH = MVI C
                             37D = 25h = BDOS Function 37 (CP/M 2.2 only)
                            205D = CDh = CALL
                             5,0 = 0005= location 5 (i.e.  CALL  BDOS)
                            201D = C9h = RET  (to dBASE2 cmd file)
 
       SET CALL TO I   {that's how you call the POKED routine
       CALL I          {
 
       RETURN            returns to the main dBASE command file
 
If anyone has an easier way of solving the problem, please post to net.
 
Eric Stork <STORK@MC>
10-Jan-84 12:48:39-MST,1060;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 12:48:33-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Jan 84 20:57 EST
Received: From Jpl-Vax.ARPA by BRL via smtp;  7 Jan 84 20:50 EST
Date: 7 Jan 1984 1745 PST
From: Bruce L. Conroy <BLC@jpl-vax>
Subject: dBase Overlay file locations
To: info-cpm@brl
Cc: stork@mit-mc
Reply-To: BLC@jpl-vax

To  set  the  drive where dBase looks for its overlay and  message  files 
there are two locations to patch. In version 2.03 there are two prototype 
file control blocks, which look like:

42cc    00 44 42 41 53 45 4d 53 47 43 4f 4d   .DBASEMSGCOM
42ed    00 44 42 41 53 45 20 20 20 4f 56 52   .DBASE   OVR
 
Changing 42cc and 42ed to 03 causes dBase to look for the files on  drive 
C.

I have looked at later versions of dBase,  and while the actual locations 
have  been changed,  all versions seem to have two of them,  between 4200 
and 4300, and the ASCII file names make them jump out on a DDT display.
------
10-Jan-84 13:13:01-MST,2051;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 13:12:54-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Jan 84 21:39 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  7 Jan 84 21:30 EST
Date: 7 January 1984 21:31 EST
From: Eric Stork <STORK@mit-mc>
To: info-cpm@brl
cc: STORK@mit-mc

Subject: Answer to my dBASE2 question
The question was:
Can someone tell me how to set up DBASE2.COM so that it can be permanently
on Disk C:, and will find its overlay files on C: even if it is
invoked from A: or B:?
In WordStar there is a location to set for where to look for
overlay files.  Logically, there should be such a location in dBASE, too.
Advice will be appreciated.
Eric.
Date: 7 Jan 1984 1745 PST

Two suggestions were received, and are shared herewith:
From: Bruce L. Conroy <BLC%JPL-VAX>
Subject: dBase Overlay file locations
Reply-To: BLC%JPL-VAX
To  set  the  drive where dBase looks for its overlay
and  message  files, there are two locations to patch
In version 2.03 there are two prototype
file control blocks, which look like:
42cc    00 44 42 41 53 45 4d 53 47 43 4f 4d   .DBASEMSGCOM
42ed    00 44 42 41 53 45 20 20 20 4f 56 52   .DBASE   OVR
Changing 42cc and 42ed to 03 causes dBase to look for the files on
drive C. I have looked at later versions of dBase,
and while the actual locations have  been changed,
all versions seem to have two of them,  between 4200
and 4300, and the ASCII file names make them jump out on a DDT display.
------
^_
Another solution:

Date:     Sat, 7 Jan 84 8:27:43 EST
From:    Rick Conn <rconn%brl>
I got around it under ZCPR2 by creating a script command like the
following:      A:;dbase setup;B:
        In this way, I have all my work on B: and dbase.com and its
overlays on A:.  The command processor goes to A:, runs dbase, and the
setup.prg file sets default to B:, so any files I reference come from B:.
When done, the trailing B: puts me back into B:.
                Rick

11-Jan-84 18:52:36-MST,762;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 11 Jan 84 18:52:31-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  8 Jan 84 17:35 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  8 Jan 84 17:24 EST
Date: Sun 8 Jan 84 14:28:22-PST
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: UTILITIES WITH CPM1.4
To: INFO-CPM@BRL.ARPA

   Users of CPM 1.4 should be aware that while the MODEM7xx
series supported 1.4, the MDM7xx series doess not, unffortunately. The NCATxx series indicates that ALLSR must be set false for CPM 1.4, but does not indicate that
DSKFRE must also be set false. Unfortunately, this valuable program can not provide the
free space left on disks in this mode.
-------
12-Jan-84 20:33:59-MST,1397;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 12 Jan 84 20:33:54-MST
Received: From uw-vlsi-gw.ARPA by BRL-VGR via smtp;  8 Jan 84 15:27 EST
Date: 8 Jan 1984 11:53:31-PST
From: Ed Mills <capn@uw-vlsi>
To: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax
Subject: My BIOS for the Ithaca Intersystems 2A.
Cc: info-cpm@brl-vgr

Mike,

	My BIOS is based on a copyrighted version distributed by Ithaca
for their system 2A with floppy drives. I can't leagally send that to anyone
who doesn't already have Ithaca's version. The version I started with is
however 2 years out of date from their current version, so if you called
them they might not object to my sending you a copy. You might also try
offering them $10 - $20, they usually just bundle it in with their CP/M.
I can send you more details before you write them a check. I have Cache
BIOS version 4h. My current version is about 50-50 theirs and mine. Their
number is 1-800-847-2088. The person to talk to is Tim Bond.

	If you just want to exchange ideas about what might belong in a BIOS,
I would love to talk to people about that. Perhaps a new list is in order?

	I neglected to keep a listing of the description I sent to the net,
so if you could send me a copy, I will fill in more details where that one
left off.

						Ed Mills

						capn@uw-vlsi

12-Jan-84 20:51:20-MST,701;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 12 Jan 84 20:51:14-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Jan 84 5:09 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  9 Jan 84 5:04 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Jan 84 1:54-PST
Date: 6 Jan 84 20:17:38-PST (Fri)
To: info-cpm@brl
From: decvax!duke!mcnc!ncsu!ncrcae!jdg@ucb-vax
Subject: 8748 Assembler wanted
Article-I.D.: ncrcae.1046

I am looking for an 8748 assembler that will run under CP/M.  Anyone knowing
of such an assembler please let me know.  Thanks.

         -----Jim Griggers
              duke!mcnc!ncsu!ncrcae!jdg
12-Jan-84 20:52:03-MST,497;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 12 Jan 84 20:51:59-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Jan 84 5:19 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  9 Jan 84 5:17 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Jan 84 2:08-PST
Date: 8 Jan 84 0:30:36-PST (Sun)
To: info-cpm@brl
From: decvax!duke!mcnc!ecsvax!hsplab@ucb-vax
Subject: cancel ecsvax.1806
Article-I.D.: ecsvax.1807


12-Jan-84 21:33:03-MST,565;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 12 Jan 84 21:32:59-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Jan 84 11:52 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  9 Jan 84 11:47 EST
Date: Mon, 9 Jan 84 07:22 PST
From: TAFEL.pasa@PARC-MAXC.ARPA
Subject: Re: stork
In-reply-to: "STORK@mit-mc.ARPA's message of 5 Jan 84 20:21 EST"
To: Eric Stork <STORK@mit-mc.ARPA>
cc: info-cpm@brl.ARPA

If you set up ZCPR on your system you will be able to do this very easyly.

Hugo.

13-Jan-84 18:55:51-MST,2465;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 18:55:44-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Jan 84 5:19 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  9 Jan 84 5:17 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Jan 84 2:08-PST
Date: 8 Jan 84 0:50:58-PST (Sun)
To: info-cpm@brl
From: decvax!duke!mcnc!ecsvax!hsplab@ucb-vax
Subject: MITS 2SIO S-100 Board Information
Article-I.D.: ecsvax.1808

Information about the MITS SIO board is available in the
S-100 Bus Handbook by Dave Bursky.  Unfortunately, I do not
have information about the jumpers.  Basically the board must
be set up to occupy 4 ports in the IO space of the 8080.  The
even ports are for control and the odd ports are for data.
There are two ports on the board.  The board uses the Motorola
6850 UARTS and data can be obtained from those data sheets.
Pins 3 and 4 on the 6850 are the receive and transmit clocks
going into the chips.  The initial setup must be done with
jumpers and a counter on those pins will tell you the initial
baud rate, the measured rate divided by 16.  The following is
an outline of the information accepted by the control port for
the purposes of initializing the 6850:

      Bits 5,6,7 control the interrupt circuits.  Since most
                 CPM software handle this poorly, especially for
                 Mits circuits, they should be set to all zeros
                 to disable them.
      Bits 2,3,4 control the parity/frame size/stop bits
                 bit 4 = 0   7 data bits; bit 4=1  8 data bits
                 bit 3 = 0   2 stop bits; bit 3=1  1 stop bit
                 bit 2 = 0   even parity; bit 2=1  odd parity
      exception: bits 4,3,2 = 100 8 bits, 2 stop bits, no parity
                              101 8 bits, 1 stop bit, no parity
      Bits 1,0   00 clock divide by 1
                 01 clock divide by 16
                 10 clock divide by 64
                 11 master reset

Since the clock is 16 time the baud rate, the effect of a divide
by 16 is to divide the baud rate by 2; divide by 64 divides the
baud rate by 4.  The initial clocks are set to one of eight rates
between 110 and 9600.  I do not think that there will be any
problems with a 1200 / 300 baud scheme being proposed.

David Chou
University of North Carolina, Chapel Hill
  ...{mcnc,unc,duke}!ecsvax!hsplab
13-Jan-84 19:05:44-MST,2230;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:05:37-MST
Received: From Sri-Nic.ARPA by BRL-VGR via smtp;  9 Jan 84 14:40 EST
Received: from USC-ECL by SRI-NIC with TCP; Mon 9 Jan 84 11:42:14-PST
Date:  9 Jan 1984 1140-PST
From: STERNLIGHT%USC-ECL@sri-nic
Subject: BYE with TRS-80 Models II/12/16
To:   info-cpm@brl-vgr
cc:   sternlight@usc-ecl

Due to mailer problems, this message may have been lost and  is  being
resent.

CP/M users of the TRS-80 Models II/12/16 with D.C.  Hayes  smartmodems
can  now use bye3-16 to set up bulletin board and downloading systems.
Include b3sio-3.asm in the bye3-16.asm file as per instructions.   Set
BYELOW  equal  to  NO.  (For some reason, with BYELOW equal to YES, at
the point where BYE wants to enter CP/M the  system  hangs,  at  least
with  Pickles  and Trout CP/M 2.2m.  If anyone figures out why, please
let me know.)  Set the other options as desired.  In the  sio  section
of  the code, set the base port address to F4 (port A) or F6 (port B).
(I do not know what value to use  for  the  baud  rate  port,  but  it
doesn't  seem  to matter if you use the setup menu of CP/M 2.2m to set
the appropriate port at, say, 300 baud and leave it  there.)   (Again,
if anyone figures that one out, please let me know.)

After assembling the program move the COM file  to  A:   drive.   Make
sure  to  rename the object code so that people don't type 'bye' in an
attempt to log off and get the bye3 program instead; again the  system
will  hang.   Instead, create a short program called 'bye' which, when
invoked, types 'please hang up now' over and  over.   Hanging  up  the
remote line will cause bye3 to reset itself for the next call.

Now reduce the size of your CP/M to leave room at the top  of  memory.
With  P&T  CP/M  2.2m, the menu commands SC and LA will get you to the
point where you can redefine the top of CP/M.  I use EFFF  with  BYE3,
instead  of the default FFFF.  After resetting the system according to
the menu instructions and setting the desired port baud rate, you  are
ready  to  type  the name of the bye3 program and you are in business.
--david--
-------
13-Jan-84 19:12:16-MST,1741;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:12:11-MST
Received: From Usc-Isid.ARPA by BRL-VGR via smtp;  10 Jan 84 9:29 EST
Date: 9 Jan 1984 21:12-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re:  How to use a TAC.
From: ABN.ISCAMS@usc-isid
To: towson@amsaa
Cc: info-cpm@brl-vgr, info-micro@brl-vgr
Message-ID: <[USC-ISID] 9-Jan-84 21:12:51.ABN.ISCAMS>
In-Reply-To: The message of     Fri, 6 Jan 84 9:28:54 EST from     David Towson (CSD) <towson@amsaa>

The TAC User Guide ain't so very small either!  However I find it invaluable.
I've also gained a certain amount of notoriety (justly so, I suppose) for
"blowing up the TAC" as my local operators fondly call it -- by following
instructions exactly (well, best as I can interpret them) for transferring
binary (8-bit) files from our host (like .COM files at SIMTEL20) through
the TAC to a micro.  B O S and B I S (the commands to switch the TAC to
binary mode don't work exactly as described -- mainly because some sort of
bug (discussed elsewhere) won't permit the TAC to reset to its normal config-
uration.  We haven't found the bug, but I have finally discovered how to log
back on to the TAC at another port (carefully writing down the number of the
original port I jammed open), and resetting that jammed port.

TAC operators are much relieved, they quit teasing me at parties, no more
threats -- but don't have it all for certain yet.  Once I figure it out, will
put a wee little supplement out on the net.   (For those poor souls with
the same brain-damaged software on the host or TAC that causes that problem.)

Regards,

David Kirschbaum
Toad Hall
(HQ XVIII Abn Corps, Ft Bragg)
13-Jan-84 19:13:51-MST,1623;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:13:46-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  10 Jan 84 9:40 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  10 Jan 84 9:30 EST
Date: 9 Jan 1984 21:22-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re:  Church Support Software Distribution
From: ABN.ISCAMS@usc-isid
To: POURNE@mit-mc
Cc: ABN.ISCAMS@usc-isid, INFO-CPM@brl
Message-ID: <[USC-ISID] 9-Jan-84 21:22:01.ABN.ISCAMS>
In-Reply-To: The message of 7 January 1984 03:54 EST from Jerry E. Pournelle <POURNE @ MIT-MC>

Sirrah,

Would be more than pleased to cooperate with fielding the Church Support
software, and have no objections to someone making back their costs and time.

HOWEVER... I have NO feedback from anyone in the world that it works!  I have
bitter, embarrassing experiences with my perfect programs that I can't crash
for trying -- and then a buddy sits down and ties the entire bloody system
into one horrible knot!

Please hold on until I can get SOME kind of feedback (good or otherwise) so
we can be sure we aren't ruining anyone's reputation (me too!) and wasting
church members' time.  And if ANYONE out there is actually running the
program, how about some feedback, huh?  Huh?  (Cooperate, and you get a
free copy of Toad Hall's world famous Kamikaze Ducks - the CP/M version
of the Osborne magazine article and listing "DUCKS" - with operational
divebombing ducks, droppings, the whole bit.  Compiled, it becomes (of course)
Hypersonic Ducks!)

Regards,
David Kirschbaum
Toad Hall
13-Jan-84 19:15:07-MST,1406;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:15:00-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  10 Jan 84 16:42 EST
Received: From Hi-Multics.ARPA by BRL via smtp;  10 Jan 84 16:21 EST
Date:  10 January 1984 08:52 cst
From:  Chan.CST@hi-multics
Subject:  buffer size in mdm716
To:  info-cpm@brl

Could someone verify that the buffer size for receiving file while in
terminal mode is about 2K for mdm716 but it is about 16K for mdm715 and
before?  Why if it is true?  This is the result that i got using
identical overlay and procedure to generate the  .com files.

I have also observed some interesting phenomenon and would like to see
whether others are having similar problem.  I discovered that while
receiving data in terminal mode with a mainframe (I tried both Multics
and a Cyber -- same results), when the buffer is filled, mdm716 sent the
XOFF to the mainframe, but then several characters following the XOFF
would screw up.  The interesting part was that they were turned into
some sort of control characters, showing up when i used mince to look at
it, e.g. "a" became "~a", "7" became "~7" etc.  However, the file would
look correct when I used Wordstar to examine it, or just "type" it, or
send it back to the mainframe using the transmit mode in terminal mode.
Is there an explanation?
13-Jan-84 19:15:49-MST,1784;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:15:43-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  11 Jan 84 4:40 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  11 Jan 84 4:30 EST
Date: 11 January 1984 04:31 EST
From: Jonathan W. Platt <JWP@mit-mc>
Subject: CP/M Plus
To: INFO-CPM@brl

	I am in the process implementing CP/M plus on a new micro
being developed.  I hope someone can answer a couple of questions.

1]  The system manual says that the CSV and ALV, found in the drive's
    DPH can be in either bank 0 or bank 1 and yet there is no bank pointer
    for these.  How do they know where it is?  Do they check to see if
    the address is below common and assume bank 0 if it is?  Could
    they possibly be placed in bank 2, say?

    I am disappointed that it looks like the BCBs have to be in common.
    I know the hash tables can be put anywhere, but is there a way to
    put the XLT, DIRBCB and DTABCB tables in another bank instead of
    common?

    In general, I think DR could have been a little more generous
    with bank pointers in their tables.  You still need too much common
    if you are making a full system and have loads of tables to deal with.


2]  The manual also says that a DRVTBL entry must be zero if the drive
    does not exist.  Could I just fill in all 16 entries with the DPH
    addresses and have SELDSK return HL=0000 (as it normally would)
    if the drive doesn't exist?  I'd like to set up all of the fixed
    tables in the BIOS ahead of time so that the system is easily
    and interactively expandable.  Total flexibility is our theme for this
    project.



			2B or D4,

			Jonathan Platt  (JWP@MIT-MC)

13-Jan-84 19:16:43-MST,1193;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:16:38-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  11 Jan 84 6:09 EST
Date: 11 January 1984 06:07 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  *** SOMEWHAT IMPORTANT on dBase2 **
To: w8sdz@brl
cc: Info-Cpm@brl-vgr
In-reply-to: Msg of Sat 7 Jan 84 15:35:13 EST from Keith Petersen <w8sdz at brl>

Your RESETT fix for Dbase 2 uses CP/M function 37 Reset Disk.

DO NOT USE THAT FUNCTION.

Function 37 has a serous bug, undocumented, that can cause CP/M
to write over the directories OF ALL DISKS it can get at,
including the A: disk, hard disks, memory drive disks, etc.  We
do not know precisely what triggers the bug; it takes a
reasonably complex pattern of disk changes and resets; but it
DOES THE JOB.  I know of three casees in which 10 megaByte hard
disks had to have their files reconstructed sector by sector
because they were bitten by CP/M FUNCTION 37.
	You must use RESET SYSTEM even though that logs you on
to the A: drive (and takes longer).  I repeat, DO NOT USE
FUNCTION 37.  You will regret it if you do.

J E Pournelle

13-Jan-84 19:18:04-MST,4376;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:17:52-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  11 Jan 84 9:26 EST
Date:     Wed, 11 Jan 84 9:19:52 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  SD-79 now available

SD version 7.9 is now available in SIMTEL20's MICRO:<CPM.DIRUTL>
directory as SD-79.ASM, SD-79.COM, and SD-79.HEX.  Sigi Kluger has
added drive/user to the command-line option so that it's now possible
to say:  A>SD B7:  to get the directory of drive B: user 7.  Other
recent changes are detailed later in this message.

SD displays the directory of a CP/M disk, sorted alphabetically, with the
file size in K, rounded to the nearest CP/M block size.  Also displays
library files with the file size in K if the '$L' option is used.

Current versions of SD will automatically adjust for any block size
and directory length under CP/M 1.4 or 2.x or MP/M (any version). They
also automatically adjust for any number of disk drives and work sat-
isfactory even if no disk is in that drive at the moment.  Provisions
are made for:

      (1) automatic pauses when the screen fills up
      (2) searching individual or multiple drives and/or user areas
      (3) unconditional or optionally resetting the disk system before
          execution begins
      (4) directing output to a disk file and appending to it on sub-
          sequent runs
      (5) summary line output giving drive and user information, # of
          files matched and how much space they consume, and the
          amount of free space remaining on the disk
      (6) displaying or suppressing "system" files
      (7) accepting ambiguous filenames with or without a drive name
      (8) printer output
      (9) can make a disk file of the results called SD.DIR
     (10) Horizontal or vertical sorting of filenames

See SD-78.DOC for detailed instructions on configuring and running SD.

-----
What's new in this, and the more recent previous versions:

12/30/83 - SD-79 - Added drive/user code (concurrent with $U). The routine
FNAME was taken from Rick Conn's SYSLIB. (FNAME.MAC).   Also fixed ^C bug.
- S. Kluger

12/24/83 - SD-78 - Fixed file and printer output code to not place the
reverse video sequences in file or on paper.  Reverted back to old SD
by renaming output file to SD.DIR.  Deleted obsolete update comments
prior to 10/1/83. - S. Kluger

11/20/83 - SD-77A - Removed 'BDOSPAG:  DB  BDOSPG' and relabeled BDOSPAG
to BDOSPG elsewhere to conform to label used in initial equates. This will
once again allow you to run BYELOW and use the 'DOPT'. This bug has existed
since SD-71. - Loren Cook

11/07/83 - SD-77 - (1). Added DORST to allow option of always doing a disk
reset if the D (all disk) option has been chosen on the command line.
Thus if a disk has been withdrawn after the last warm boot, the program
will not hang at the empty drive as the program automatically does the
warm boot before reading the disk directories.  An RCPM (have to think of
them or incur a little criticism) or others with just a hard disk setup
would set this equate to NO to prohibit the disk reset, but those using
floppies should find it better than trying to remember to do a Ctl-C after
removing a disk.  Setting both AUTOR & DORST to YES will not result in a
double disk reset, but will always do 1 reset.  Setting just DORST to YES
will force a reset ONLY when the D option is specified on the command line.
(2). Eliminated label LLENLOT as it wasn't used for anything and caused a
"Multiple Definition" error when assembling with RMAC.  (3). Added code to
always start search at user 0 when A option specified on command line.  Now
you can say:

         C3> SD filename $AD   - to start at A0: 
    or
         C3> SD filename $U2AD - to start at A2:

Also note again, if NODISK is set to YES at assembly time, a drive does NOT
have to be specified for the above command.  (4). Fixed glitch which caused
turn-up of 1 extra blank line when last library had a full line of member
files.  (5). Reinstated ability to limit $D option by specifying a starting
drive.  SD B: $D will now start searching on drive B.  Note that  SD $D will
always start on drive A. - Dennis Vallianos

--end--
13-Jan-84 19:19:59-MST,1201;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:19:53-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  11 Jan 84 15:17 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  11 Jan 84 15:04 EST
Date: 11 Jan 1984 14:42-EST
From: Conal.Elliott@CMU-CS-CAD.ARPA
Subject: atari <--> cpm question
To: info-atari@su-score, info-cpm@mit-mc
Message-Id: <442698124/conal@CMU-CS-CAD>

It is possible to make CP/M readable files with an atari computer and
disk drive, or alternately, to read an atari disk with a CP/M system,
both without hardware modifications?  Are the problems physical
incompatability, or can they be bypassed with low-level software
mucking about?  (Both use soft-sectored 5 1/4 disks.)

I have an atari 800 with an atari 810 and astra 1620 disk drives and
Jack Palevich's "Chamelon" terminal program, and want to copy some of
the archived public-domain CP/M software and send it to my younger
brother, who uses a CP/M 2.2 based computer.  Any suggestions would be
greatly appreciated.

				- Conal

P.S. I'm not on the info-cpm list, so any cp/m people, please respond
directly to me.  Thanks.

13-Jan-84 19:20:09-MST,1449;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:20:05-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  11 Jan 84 14:48 EST
Received: From Hi-Multics.ARPA by BRL via smtp;  11 Jan 84 14:43 EST
Date:  11 January 1984 13:39 cst
From:  Chan.CST@hi-multics
Subject:  buffer size in mdm716
To:  info-cpm@brl
Acknowledge-To:  Chan.CST at HI-MULTICS


Could someone verify that the buffer size for receiving file while in
terminal mode is about 2K for mdm716 but it is about 16K for mdm715 and
before?  Why if it is true?  This is the result that i got using
identical overlay and procedure to generate the  .com files.

I have also observed some interesting phenomenon and would like to see
whether others are having similar problem.  I discovered that while
receiving data in terminal mode with a mainframe (I tried both Multics
and a Cyber -- same results), when the buffer is filled, mdm716 sent the
XOFF to the mainframe, but then several characters following the XOFF
would screw up.  The interesting part was that they were turned into
some sort of control characters, showing up when i used mince to look at
it, e.g. "a" became "~a", "7" became "~7" etc.  However, the file would
look correct when I used Wordstar to examine it, or just "type" it, or
send it back to the mainframe using the transmit mode in terminal mode.
Is there an explanation?
13-Jan-84 19:22:04-MST,1110;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:21:59-MST
Received: From Brl-Bmd.ARPA by BRL-VGR via smtp;  11 Jan 84 19:49 EST
Date:     Wed, 11 Jan 84 19:49:08 EST
From:     Charlie Strom (NYU) <strom@brl-bmd>
To:       Chan.CST@hi-multics
cc:       INFO-CPM@brl-vgr
Subject:  Re:  buffer size in mdm716


You are quite correct that MDM716 has a 2K buffer rather than a 16K buufer.
Being a devoted YAM user, I have not yet fiddled with 716, but there have
been a number of complaints from users on Compuserve. I hope that Plouffe
can advise us of the rationale for the change.
The problem with extra characters (after buffer fill) that was determined
to be a problem on CIS is that the routine used in MDM7 AFTER the buffer is
filled does not strip parity, whereas the normal ASCII capture routine does.
A simple fix would be to run the received file through PIP with the [Z] option
set. Irv Hoff is hoping to release a new version fixing this. Of course
you might tell your mainframe not to use parity if that is possible.
13-Jan-84 19:23:53-MST,1613;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:23:48-MST
Received: From Brl-Bmd.ARPA by BRL-VGR via smtp;  11 Jan 84 21:53 EST
Date:     Wed, 11 Jan 84 21:40:07 EST
From:     Keith Petersen <w8sdz@brl-bmd>
To:       Charlie Strom (NYU) <strom@brl-bmd>
cc:       Chan.CST@hi-multics, INFO-CPM@brl-vgr
Subject:  Re:  buffer size in mdm716

Please tell Irv Hoff that Bob Plouffe and Ron Fowler already have MDM717
"in progress" and we should have something forthcoming from them with
these fixes in about a week.  I'd hate to see all that good stuff that
Bob Plouffe put in MDM716 "stripped out" by Irv "because he doesn't
agree with it" or "doesn't like it".  That's how we lost the "retry
after ten errors" option, amoung other things.

On the subject of the 2k buffer size.  This is true ONLY for the
protocol file transfer mode.  It does not affect the terminal
capture mode.  It was done after NUMEROUS complaints from people
with slower disk systems which took so long writing the 16k buffer
out (and consequently closing that extent and opening the next
in the directory) that they lost the next sector and several tries
from the sender.  In many cases this caused the transfer to abort.
The 2k buffer was chosen MANY versions back (when the program was
MODEM2) as an acceptable compromise between disk access speed
and the improvement in receiving speed by putting the characters
into the buffer instead of writing every sector (which was the
way Ward Christensen's old original MODEM program worked) to the
disk.
13-Jan-84 19:33:03-MST,978;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:32:59-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Jan 84 6:16 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  12 Jan 84 6:08 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 12 Jan 84 2:56-PST
Date: 10 Jan 84 5:50:09-PST (Tue)
To: info-cpm@brl
From: harpo!floyd!clyde!burl!ars@ucb-vax
Subject: Terminal Emulator Program Wanted for DECmate II
Article-I.D.: burl.396

I am looking for a Public Domain terminal program for the DECmate
II.  I am using the DECmate II with the cpm option.  I have DEC's
WPS communications package but that is of no help for uploading and
downloading files to cpm.  Any help would be appreciated.
Thanks
			Allen R. Shuff -- 919-697-4339 (Cornet 292) 
			...![ floyd clyde ihnp4 mhuxv ]!burl!ars
-- 
Allen R. Shuff -- 919-697-4339 (Cornet 292) 
...![ floyd clyde ihnp4 mhuxv ]!burl!ars
13-Jan-84 19:37:18-MST,1314;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:37:14-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Jan 84 8:46 EST
Date:     Thu, 12 Jan 84 8:38:14 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Patching MDM716.ASM for Hayes result codes

Date: 01/01/84 11:30:07
From: Bob Plouffe
To:   Frank Wancho
Re:   Patching MDM716 for Smart Modem result codes

	Regarding failure of MDM716 to go to terminal mode
after dial commection is made, try changing the SMRESUL1
routine to the following code.  I assume you are using a
SmartModem which has both verbose and numeric result codes
depending on how your modem switches are set.  This code will
work regardles which way the result code switch is set. I have
it implemented this way in my version for the IBMPC and hadn't
noticed that it wasn't implemented properly in MDM7xx.

SMRESUL1:
	CALL	IN$MODDATP	
	ANI	7FH		
	MOV	B,A		
	CPI	'C'
	JZ	CONMADE1	
	CPI	1
	JZ	CONMADE1
	CPI	'E'
	JZ	GIVLF
	CPI	4
	JZ	GIVLF
	CPI	'N'
	JZ	SMDM1
	CPI	3
	JNZ	SMRESULT

This should be a permanent change to MDM7xx and I will put it
into the next release.  In the meantime, perhaps it should be
put on the nets as a patch.
				Bob Plouffe
13-Jan-84 19:44:10-MST,1879;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:44:04-MST
Received: From Parc-Maxc.ARPA by BRL-VGR via smtp;  12 Jan 84 14:11 EST
Date: Thu, 12 Jan 84 10:59 PST
From: MMOON.ES@PARC-MAXC.ARPA
Subject: Re: BIOS
In-reply-to: "capn@uw-vlsi.ARPA's message of 8 Jan 84 11:53:31 PST"
To: Ed Mills <capn@uw-vlsi.ARPA>
cc: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax.ARPA, 
    info-cpm@brl-vgr.ARPA

I would dearly like to see BIOS information put out in the public
domain.  While different hardware manufacturers have every right to
copyright their particular code, I see no reason not to exchange ideas
on the generalized techniques involved in a particular subroutine or
task without the gory details of a peculiar implimentation.  If the idea
is one's own, of course the publishing of source code is a personal
decision.  It may be more appropriate to put the technique down in some
form of pseudo-code since, CP/M is no longer tied to a small group of
code-compatible processors.  I feel this list is an appropriate forum,
but would certainly add myself to any other on which the discussion took
place.  I will suggest a few topics I would like to see and participate
in discussions on:

	1)Interrupt drivers for anything, but particularly floppy controllers
	2)Pointer interfaces, e. g., mice, touchpads, etc.
	3)Bdos call trapping
	4)Any public-domain LRU or other buffering techniques for flavors of
CP/M which don't already employ the same


Having a pool of techniques for even the more mundane and necessary
stuff needed for baseline systems would be incredibly useful for those
of us with the unstoppable urge to hack hardware, not to mention the
poor people who can't get their manufacturer to supply BIOS source.

I'll be watching this develop.

			MMoon.es


13-Jan-84 19:49:14-MST,636;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:49:11-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Jan 84 17:49 EST
Received: From Usc-Eclb.ARPA by BRL via smtp;  12 Jan 84 17:38 EST
Date: 12 Jan 1984 1438-PST
From: Dick <MEAD@usc-eclb>
Subject: NSWP199H
To: info-cpm@brl

From reading the doc file on the 'LAST' update to a nice program,
it looks as though SQ/USQ is supposed to work, but I have not been
able to get the Squeeze functioon to work. All I get is the message,
"can't squeeze yet" ...  Is this never going to be fixed?
-------
13-Jan-84 19:50:43-MST,1241;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:50:37-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Jan 84 9:02 EST
Date:     Thu, 12 Jan 84 8:48:41 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  MDM716 RV bug fix

MDM716 has a problem when you try to "View" an incoming received
ASCII file (.i.e., using the RV command).  Dick Mead has found the
problem and offers the fix below, which is easily done with DDT.
After the patch, the View mode works but displays the sector headers
in hex - apparently a problem with one of the View flags.  This will
be fixed in the next version.

---forwarded message--

Date:  5 Jan 1984 2246-PST
From:  Dick Mead
Re:    MDM716 RV bug fix
To:    Info-Modem7@MC

In case no one else has had the time to look at the bug Keith pointed
out with Receive View mode in MDM716, I seem to have stumbled across it.

At label -->    MONIN: POP PSW
                       PUSH PSW
                       CALL SHOW
                       PUSH PSW  <------this is the culprit

I NOP'ed the byte and the RV mode works fine, this shows up as an F5
at location 2571H.

Dick....
13-Jan-84 19:51:07-MST,1322;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:51:03-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Jan 84 19:01 EST
Received: From Jpl-Vax.ARPA by BRL via smtp;  12 Jan 84 18:58 EST
Date: 12 Jan 1984 1555 PST
From: Bruce L. Conroy <BLC@jpl-vax>
Subject: Use of dBase RESET function.
To: info-cpm@brl
Cc: stork@mit-mc
Reply-To: BLC@jpl-vax

     Although  there are some funny effects in dBase's RESET 
command I have found it to be 100% reliable under several 
versions of dBase if:

     a)   Any files on the disk to be changed are closed 
(this is merely good practice in any event,)

     b)   The disk is changed, then

     c)   The command RESET (not RESET B) is given.

     In particular, this sequence avoids the following 
anomolies:

     a)   RESET B or RESET B: or any similar command seems 
to have no effect whatever.

     b)   As long as a data file is open, there is an 
unpredicable amount of data in memory, which is not on disk. 
If the disk is changed at this point these data are lost, 
unless

     c)   There is a file of the same name on the new disk, 
in which case, the extra data are stuffed into that file,
resulting in the loss of the integrity of both data files.
------
13-Jan-84 19:53:44-MST,907;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:53:40-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Jan 84 20:23 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  12 Jan 84 20:17 EST
Date: 12 January 1984 20:17 EST
From: Eric Stork <STORK@mit-mc>
To: info-cpm@brl
cc: STORK@mit-mc

Subject: Need MODEM7xx for EAGLE

A friend of mine has an EAGLE z-80, cp/m 2.2, 5" drive.
He needs MODEM7xx, prferably set up for SModem (Hayes).
If you can help, pls respond direct to me and i'll get you
together with him.  Or, if you're in
LAX areea, give him a call direct.  His name:
Ernie Rosenberg, home:(213)501-0756 (yes, really 501-)
office:(213)486-6098.
Ernie and I want to communicate
by modem, but until he has  MODEM7xx, we can't begin and I can't
help him because I'm 8" CP/M.
Thanks for any help,

Eric.

13-Jan-84 19:55:08-MST,524;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:55:05-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Jan 84 20:44 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  12 Jan 84 20:37 EST
Date: 12 January 1984 20:22 EST
From: Eric Stork <STORK@mit-mc>
To: info-cpm@brl

Subject: Correction re EAGLE MODEM7xx need.

The guy who needs the MODEM7xx for the CP/M Eagle, Ernie R,
is at (213)501-0736, NOT 0756 as I said before.
Sorry

Eric
13-Jan-84 19:56:34-MST,1302;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:56:30-MST
Received: From Usc-Isid.ARPA by BRL-VGR via smtp;  12 Jan 84 22:34 EST
Date: 12 Jan 1984 13:55-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re: My BIOS for the Ithaca Intersystems 2A.
From: ABN.ISCAMS@usc-isid
To: capn@uw-vlsi
Cc: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax
Cc: info-cpm@brl-vgr
Message-ID: <[USC-ISID]12-Jan-84 13:55:15.ABN.ISCAMS>
In-Reply-To: The message of 8 Jan 1984 11:53:31-PST from Ed Mills <capn@uw-vlsi>

Reference exchanging ideas about what might belong in a BIOS...

I too am very interested, since I dearly love hacking about in my own
Morrow Decision I CBIOS&.

I understand the copyright problem (and agree with something like a BIOS),
but I wonder what the ethical (and maybe legal) line is on sending parts
of one to show how something is done, or to show the environment in whichd
a particular hack fits.  Like, if I invent a new wonderful I/O procedure,
or how to set parity or something -- can I show the "before" and "after"
without upsetting someone?

Anyone know the legal niceties about this?  Or a net opinion on the
ethics?  Would be glad to summarize.

David Kirschbaum
Toad Hall
(ABN.ISCAMS@USC-ISID)
13-Jan-84 19:58:10-MST,1422;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:58:06-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Jan 84 22:36 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  12 Jan 84 22:34 EST
Date: 12 Jan 1984 14:03-PST
Sender: ABN.ISCAMS@usc-isid
Subject: SPELL and its DICT.DIC
From: ABN.ISCAMS@usc-isid
To: INFO-CPM@brl
Message-ID: <[USC-ISID]12-Jan-84 14:03:31.ABN.ISCAMS>

You all may know SPELL (a nice public domain spelling checker) and an
ITS-binary format dictionary, DICT.DIC are out on SIMTEL20 under
MICRO:<CPM.SPELL>SPELL.(MAC, COM).1 and DICT.DIC.1

If you have a particularly brain-damaged TAC like mine, you may find it
difficult to download an 8-bit binary file to your micro.  And if you
lost the pointers to a particular utilityl on TOPS-20 (I think) that
converts ITS-Binary files to regular 8-bit binary (by stripping off
the first 32-bit word, I guess), you may find it even harder to get that
DICT.DIC to run!

I solved both problems, and if anyone wants a (somewhat lengthy) How To
(right down at the novice, how to figure SAVE pages in DDT, level) --
message me.  Don't want to inflict it on the net.

If the SIMTEL20 MICRO: Sysop is out there, and if there's enough
interest in this, maybe you'd like to put it in the <CPM.SPELL> directory.

David Kirschbaum
Toad Hall
(ABN.ISCAMS@USC-ISID)
16-Jan-84 09:41:54-MST,2750;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:41:38-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  15 Jan 84 11:40 EST
Date:     Sun, 15 Jan 84 11:26:18 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Function 37 disk reset and dBase

With all the discussion about CP/M's function 37 disk reset, I thought
a review of the following file, UNDOCCPM.DOC, might be useful.

It's likely that function 37 causes any open files to be closed and
then when DBASE writes to the file it THINKS is still open, it causes
CP/M to write the data to the directory tracks.  The solution, of course
is to tell DBASE to close the files first before doing the reset.
--Keith

-----
August 12, 1982

TO:   All CP/M assembly programmers
FROM: Thomas Hill
      200 Oklahoma
      Anchorage, Ak.  99504
      (907) - 337-1984

SUBJECT: Undocumented CP/M BDOS Features

Just a short note to aquaint you with an "undocumented feature" I have 
encountered in the CP/M 2.2 BDOS.  While developing an assembly program 
which read and wrote disk files, an early version did not open the 
output file before writing to it.  Oddly enough, the BDOS accepted the 
write and did not return an error condition.  Being a curious soul
(and cautious), I sidetracked to investigate this effect.  A call to 
Digital Research resulted in a letter informing me that they knew of the 
effect and told me it was an "undocumented feature" of CP/M.  They also 
told me that it was the programmer's responsibility to open and close 
his files properly, to which a heartily agree.

However.  I wrote some test programs to determine WHERE on the disk the 
information was going, and WHAT happened to the valid data on the disk.
Writing to an unopened file apparently writes information beginning at 
Group 0, sector 1 and continues in a sequential manner thru the 
allocation map.  (I lost three directories that way).  No change is made 
in the allocation map, however, and the only change in the File Control 
Block is the Current Record and Next Record fields are incremented.  NO
CHANGE occurs in the FCB allocation map.

While it is, of course, the programmer's responsibility to control the 
file accesses, and proper opening and closing is mandatory, in some 
cases (particularly during program development), proper file access may 
not take place.  If this occurs, a possible loss of data may result.
There may be a BDOS patch which will clear this up, or someone out there 
may already have one.  If anyone knows more about this, I would 
appreciate it if you would drop me a line at the above address.

Thanks,
Thomas Hill
16-Jan-84 09:43:16-MST,451;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:43:00-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  15 Jan 84 16:32 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  15 Jan 84 16:17 EST
Date: 15 January 1984 16:20 EST
From: Richard P. Wilkes <RICK@mit-mc>
Subject:  Remove from list
To: info-cpm@brl


Please remove RICK at MIT-MC from the CPM list.  Thanks. -r

16-Jan-84 09:43:56-MST,791;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:43:48-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  11 Jan 84 21:27 EST
Date: 11 Jan 1984  19:25 MST (Wed)
Message-ID: <WANCHO.11982890842.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@simtel20>
To:   INFO-CPM@brl-vgr
Subject: Lots of new files available!

With the help of Bill Westfield's NMODEM (in batch upload mode) AND
Bob Plouffe's ruggedized MDM716, our operator, Dave Tapia, was able to
finally upload (with CRCs checked), all the remaining SIG/M volumes on
hand.

This brings our online collection to 213 disk volumes:

SIG/M #000 - 145 (MICRO:<SIGM.VOLnnn>)

CPMUG #001 - 054 (MICRO:<CPMUG.VOLnnn>)
      #078 - 090

Enjoy!

--Frank
16-Jan-84 09:44:00-MST,487;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:43:55-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  15 Jan 84 20:21 EST
Received: From Bnl.ARPA by BRL via smtp;  15 Jan 84 20:15 EST
Date: 14-Jan-84 00:59:54-EST
From: jpm@bnl
Subject: January Byte
To: info-cpm@brl, info-micro@brl

Did anybody get their copy of the January Byte yet? Is it just
very late this month, or did Los Angeles get left out?
16-Jan-84 09:45:18-MST,580;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:45:15-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  15 Jan 84 20:21 EST
Received: From Bnl.ARPA by BRL via smtp;  15 Jan 84 20:15 EST
Date: 14-Jan-84 23:57:01-EST
From: jpm@bnl
Subject: Byte finally showed up
To: info-micro@brl, info-cpm@brl
Cc: jpm@BRL.ARPA

I want to thank the 10 or so people who told me the status of
their January issue of Byte. I just got mine today. It seems
that the west coast was just a bit late in getting theirs.
16-Jan-84 09:48:20-MST,3229;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:48:10-MST
Received: From Sri-Nic.ARPA by BRL-VGR via smtp;  16 Jan 84 2:42 EST
Received: from USC-ECLB by SRI-NIC with TCP; Sun 15 Jan 84 23:42:02-PST
Date: 15 January 1984  23:36-PST (Sunday)
Sender: TLI@usc-eclb
From: Tony Li <Tli@usc-eclb>
To:   Info-Cpm@brl-vgr
Subject: Function 37
Reply-to: Tli@usc-eclb
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168


All right, if were really going to discuss this, let me give you a
copy of my source.  The following is the description of Function 37
from the CCP/M-86 manual.  Admittedly, this isn't the same as the CP/M
2.2 filesystem, but I would be surprised if there were any significant
differences.  Anyhow:

----------------------------------------------------------------------

			DRV_RESET

		Reset Specified Disk Drives

	Entry Parameters:

		Register CL : 025H (37)
			 DX : Drive Vector

	Returned Values:

			 AL : Return Code
			 BL : Same as AL

The DRV_RESET system call is used to programmatically restore
specified removable media drives to the reset state (a reset drive is
not logged in and is in Read-Write status). [Presumably there are no
files open on a drive which is not logged in. - Tony]  The passed
parameter in register DX is a 16-bit vector of drives to be reset,
where the least significant bit corresponds to drive A, and the
high-order bit corresponds to the sixteenth drive, labelled P.  Bit
values of 1 indicate that the specified drive is to be reset.  Refer
to Section 2.17 [CCP/M-86 1.0 Programmers Guide] for more information
regarding the use of this system call.

This system call is conditional under Concurrent CP/M-86.  If another
process has a file open on any of the drives to be reset, the
DRV_RESET system call is denied, and none of the drives are reset.

Upon return, if the reset operation is successful, DRV_RESET sets
register AL to 00H.  Otherwise, it sets register AH to 0FFH.  If the
BDOS Error mode is not in Return Error mode (refer to the F_ERRMODE
system call), the system displays an error message at the console
identifying the process owning the first open file that caused the
DRV_RESET request to be denied.

----------------------------------------------------------------------

Section 2.17 goes on to stipulate that "If all the open files on a
removable drive belong to the calling process, the process is said to
'own' the drive.  In this case, the file system performs a qualified
reset on the drive and returns a successful result.  This means that
the next time a process accesses this drive, the BDOS performs the
log-in operation only if it detects a media change on the drive."

----------------------------------------------------------------------

Conclusion: In the safest case, one should close all files before
performing a DRV_RESET.  However, if you do not, and your BIOS is
somewhat flakey about detecting a media change (or your hardware is),
you might not get the reset.  This would probably result in
destruction of the newly inserted media, as has been described by JEP.

Cheers,
Tony ;-)
16-Jan-84 09:50:04-MST,979;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:49:56-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  13 Jan 84 2:42 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  13 Jan 84 2:36 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 12 Jan 84 23:24-PST
Date: 6 Jan 84 13:25:48-PST (Fri)
To: info-cpm@brl
From: hplabs!sdcrdcf!trw-unix!scgvaxd!ns05040@ucb-vax
Subject: problem with async i/o on Big Board (HELP!)
Article-I.D.: scgvaxd.159

I have recently built a Big Board and I am attempting to use it
as a teminal (initially) to our UNIX system.

I have had some difficulty understanding Zilog's documentation on
the Z80 SIO as evidenced by the fact I cannot get either SIO A or B
to give me anything on a write other than transmit data overrun??

If anyone has any experience with this particular system I sure
would like to here from you.

				thanks
				Norm Scherer
16-Jan-84 09:50:20-MST,1036;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:50:14-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  13 Jan 84 9:01 EST
Date:     Fri, 13 Jan 84 8:52:01 EST
From:     "Richard G. Turner" <rturner@brl>
To:       info-cpm@brl
Subject:  BYE3 -- KayPro II

Gentlefolken,

I'm relatively new to the CP/M world, and even though I have made my
living as a programmer at times, I'm over the hill, so to speak, as
a hacker.

I'd like to hear (directly, not to tie up this list) from anyone who
has a similar configuration to mine, or as close as possible:

	KayPro II [CP/M 2.2]
	Hayes Smartmodem 300
	Epson look-alike printer

I'm especially interested in hearing from anyone who has gotten BYE3
to work in this configuration. I can get BYE to answer the modem, but
the system turns into a pumpkin after that.

I have been reasonably successful with some of the public domain
software at SIMTEL20; MODEM716 runs great guns!

Thanks,
rick
16-Jan-84 09:50:58-MST,2976;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:50:49-MST
Received: From Brl-Voc.ARPA by BRL-VGR via smtp;  13 Jan 84 9:46 EST
Date:     Fri, 13 Jan 84 9:36:31 EST
From:     "Ferd Brundick (LTTB)" <fsbrn@brl-voc>
To:       Mike Simpson <msimpson@bbn-unix>, Pete Criqui <ihnp4!hlhop!pcc@ucb-vax>
cc:       info-micro@brl-vgr, info-cpm@brl-vgr
Subject:  Re:  WordStar printer questions

Hi,

There are at least 4 ways that you can get Word* to print special characters
and control sequences --

1. Install your own routines in ^Q, ^W, ^E, ^R and ribbon change.  If you
modify the ribbon change sequence (I use it to turn off enhanced printing)
you can patch the help file as well so that the NoFile Menu has the correct
prompt.  This method only works for very short sequences.

2. Write your own printer driver and install it in WS.  There are a few
control chars that WS doesn't use, and your driver could use these as
special flags to change the meaning of the next char(s).  For example,
^]A could mean "print an Alpha", ^]B --> print a Beta, etc.

3. Write the same printer driver but install it in your CBIOS.  This is a
bit more involved (depending on whether or not you have a source listing)
but has the advantage that all programs that talk to your printer would
be able to use the special chars/features.  This is the method that I
prefer and am slowly working on.  A recent issue of MicroSystems had an
article/program that used this technique.

4. Write a new utility program that prints WS files (instead of using WS's
print routine).  This would be a large program and something that you
would probably not do Except for the fact that it has already been done.
The January 84 issue of Interface Age has an article in MBASIC (plus a
small assembler sbr to send chars to the printer) that uses true proportional
spacing to print a WS file.  Of course it also can also access your printer's
special abilities as well, but does not print non-ASCII chars.  I have
begun converting this program into 8080 assembler for 3 reasons:
   a) It only prints 8 lines per minute
   b) I think the author made 2 major mistakes
   c) I don't have MBASIC.
The author does mention that he is also rewriting it in assembler.

If anyone else "out there" is pursuing a project such as this I would be
interested in hearing from you.  I have a NEC PC-8001 and 8023 printer.
The MicroSystems article was written for a North*/8023 combo and the IA
article is for the ProWriter printer.  The 8023 and ProWriter are 
different versions of the same basic dot-matrix printer made by TEC, as
are a printer by Panasonic and the (newest?) Apple printer.

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>
16-Jan-84 09:51:48-MST,1012;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:51:36-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  13 Jan 84 12:58 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  13 Jan 84 10:59 EST
Date: 13 Jan 1984 07:57-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re:  buffer size in mdm716
From: ABN.ISCAMS@usc-isid
To: Chan.CST@hi-multics
Cc: info-cpm@brl
Message-ID: <[USC-ISID]13-Jan-84 07:57:34.ABN.ISCAMS>
In-Reply-To: The message of  11 January 1984 13:39 cst from  Chan.CST@hi-multics

Ref the little ~ character showing up sometimes in MDM716 --

I see the same thing in my earlier MDM's, and also in KERMIT and other
terminal programs.  Not all the time - just under certain conditions.
It doesn't show up in my files, but appears to be something that went up
to the host and echoed back to me.  I believe I can delete it up on
the host.  Donno what it is - but appears to be harmless.

David Kirschbaum
Toad Hall
16-Jan-84 09:54:56-MST,551;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:54:53-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 6:33 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  16 Jan 84 4:42 EST
Date: 16 January 1984 04:46 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Byte finally showed up
To: jpm@bnl
cc: info-cpm@brl, info-micro@brl, jpm@brl
In-reply-to: Msg of 14-Jan-84 23:57:01-EST from jpm at bnl

Heck I GOT MY BYTE for Jan on Saturday 14 Jan!  Ye gods.

16-Jan-84 09:56:37-MST,970;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:56:33-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 6:07 EST
Date:     Sat, 14 Jan 84 0:51:13 EST
From:     Keith Petersen <w8sdz@brl>
To:       Richard G. Turner <rturner@brl>
cc:       Info-Cpm@brl-vgr
Subject:  Re:  BYE3 -- KayPro II

Get BYE3-17.ASM and the BY2SMDM something file (I forget it's name)
from the SIMTEL20 MICRO:<CPM.BYE3> directory.  This version fixed
a problem in 3-16 that's probably causing it not to run on your system.

If you like MDM716, you'll love MDM717.  You can get it from SIMTEL20
Monday, or if you want it earlier you can FTP it from MIT-MC.  It's
in the following files there:

FJW;MDM717 ASM
FJW:MDM717 COM
FJW:MDM717 HEX
FJW:MDM717 MSG

Suggest you read the MSG file first.  You don't need the ASM file
to make it run, as you know.  You can use your present overlay
file.
16-Jan-84 09:56:57-MST,4065;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:56:45-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 6:07 EST
Date:     Sat, 14 Jan 84 0:55:01 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Hoff notes on MDM717 update

Forwarded message from Irv Hoff to Dave Hardy and myself...

---
01/12/84
Hi Dave / Keith

Here is MDM717 as promised.  Took longer than I had planned.  Paul
Grupp was telling me about a problem with the "V" flag.  Took me
most of the day to track that down as it was actual a dual problem.
(1) stack problem in the MOmin area and (2) a DATAFLG problem in
the RCVCHR area that took quite awhile to track down.  That one
caused the results with "V" to be similar to those with "R" and
showed the non-ASCII characters as (0D) hex characters when it
wasn't supposed to.  The stack problem of course just bombed things.

Dave Mabry also pointed out a problem with the LOGON message being
inconsistent at times.  (I had noticed that also but rarely use it and
did not get around to tracking down the problem until yesterday.  I
am pretty sure that is solved now, I can't get it to act up any more
on several different systems, and don't see how it can, now.

The main thing I got into MDM717 for was to fix a problem the fellows
are having on Compuserve with "save to disk".  Since many do not have
BUFEXC or CSEXEC, they just download ASCII files directly to disk (and
take their changes on no errors).  But MDM716 was saving to disk every
2k (instead of every 16k like I had it set for, Plouffe changed that,
it's now back to 16k with a note to leave it that way for distribution
copies and if an individual user wants to change it later, fine.)  When
set for 2k the problem during transfer to disk was aggravated badly.

I was stripping off parity from incoming characters but failed to also
do that during the time we picked up propagation delayed characters re-
ceived after an X-off.   It was very simple to fix with an ANI 7FH in
the INMODEM area.  Then started finding things that needed to be done
with MDM716.

Now I did not change anything Plouffe did, basically.  I was going to,
then decided against it.  All I really did was add an option to use
what he has now for GETACK, or with ACKNAK set to "normal ('YES') for
RCPM, it resends the sector immediately on any non-ACK.  Since XMODEM
will time out with 10 errors, we do not ask if you want to "try again"
after you get 10 errors - knowing that XMODEM has already terminated
the file transfer at the RCPM end.   But with ACKNAK set for ARPANET
to "NO", you only resend a file with a valid NAK.  This can take up to
about 1-1/2 minutes the way Plouffe re-did the GETACK area, for each
error.  After 10 errors, it THEN asks you if you want to continue.

So think we have the best of both worlds, now, and Plouffe should be
happy, and I guess I am too.  It's all automatic, with how you set the
equate at ACKNAK.

That about takes care of things.  With any luck, this version will last
3-4 days before Sigi Kluger or somebody decides to take yet another
crack at it.

It is possibly my last effort at MDM7-anything.  My next "big deal" is
going to be called either "MU-1" or "MC-1" or "MCU-1" have not made up
my mind yet.  Will support RCPM and CIS protocols, and include BUFEXC
as part of the program.  Will be a little more along the lines of YAM,
perhaps.  Only assembly level source.

This is already on several west coast systems now.  These systems are
so private the three big ones in this area are talking about going re-
stricted on users.  Maybe something along the lines of what Gary
Shaffstall is doing in Denver or even Jud Newell.  Hate to see that, but
it is getting impossible to get on some of these at all, without calling
on the voice line and making a schedule.  Auto-dial would be nice, but
one hates to work that hard to give programs away!

				Best regards,      Irv

16-Jan-84 09:57:08-MST,485;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:57:05-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 6:08 EST
Received: From Bnl.ARPA by BRL via smtp;  14 Jan 84 0:55 EST
Date: 14-Jan-84 00:59:54-EST
From: jpm@bnl
Subject: January Byte
To: info-cpm@brl, info-micro@brl

Did anybody get their copy of the January Byte yet? Is it just
very late this month, or did Los Angeles get left out?
16-Jan-84 09:57:42-MST,3678;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:57:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 6:08 EST
Date:     Sat, 14 Jan 84 0:56:03 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  MDM717.MSG


TOPIC:	MDM717.ASM MODEM PROGRAM

FROM :	IRV HOFF W6FFC

DATE :	11 JAN 84


	NOTE:  	This program when assembled is 69 sectors
	       	long.  Use this figure when merging the
	       	appropriate overlay file for your computer
		via DDT, etc.  (Most of the overlays were
		written when MDM7xx.COM was only 66 sectors
		and the example included in each says to
		store 66 sectors.)  For MDM717 use:

			B>SAVE 69 MDM717.COM

	NOTE:	If using the phone number overlay to change
		the phone library numbers, be sure to use:

			ORG	0D00H


     Most users will not need the lengthy (152k) source code at all.
     Just get MDM717.COM and then check one of the associated over-
     lay programs to obtain the overlay for your particular computer.
     Merge that with MDM717.COM according to the instructions near
     the start of the overlay file, using DDT.COM, etc.  (See above
     note relative to saving 69 sectors.  STAT.COM would then show
     138 records for 18k.)


CURRENT CHANGES FOR MDM717
--------------------------	

     MDM717 allows characters with parity bit set to be properly handled
during propagation overruns after an X-off.  This occurs during a "save
to disk" after the disk buffer fills.  (This problem was noticed on Com-
puserve which sends some characters with the parity bit set.)

     The disk buffer size was restored to 16k.  This is the length of
"one file extent".  Even slow floppy disks can store 16k in a reason-
able amount of time.  This should remain 16k for distribution copies of
the source code although it can be easily changed to suit the individual
user's own preference.  (It could even be lengthened to 32k if you like
fewer disk operations.  This would make the printer buffer proportion-
ally smaller but most printers are so fast the buffer is rarely filled
in any case.)

     Fixed a stack problem introduced in v716 in the "V" flag routine to
allow the user to show ASCII characters on the CRT during a file trans-
fer.

     Fixed the "L" Logon feature so it should be consistent.  At times
it would run away without waiting for the echo characters, thus not cor-
-rectly displaying the Logon message.

     Restored the ACKNAK feature developed for the exclusive use of the
ARPANET networking group.  When set normal ("YES") it resends a disk re-
cord after any NON-ACK character is received.  This has been the normal
configuration for all RCPM systems using the XMODEM file transfer pro-
gram.  When set "NO" for ARPANET use, it resends a record only after a
NAK has been received.  Other characters are ignored.  Some systems will
resend a NAK after a 10-second TIMEOUT.  This slows things considerably,
which allows the main frame time to recover if busy.  This tends to run
the phone bill higher for RCPM use, but is necessary for ARPANET to pre-
vent aborting the file transfer too quickly if the main frame is busy.
If a normal TIMEOUT sequence does attempt to abort the transfer with the
ACKNAK equate set to NO, it will ask if you want to try again or abort.
(RCPM systems would have already timed completely out with 10 consecutive
errors, making the question worthless and misleading.  ARPANET does not
have a similar feature, and the user can manually force the transfer to
continue.)

				- Irv Hoff


16-Jan-84 09:58:46-MST,816;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:58:33-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 6:09 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  14 Jan 84 4:32 EST
Date: 14 January 1984 04:35 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Use of dBase RESET function.
To: BLC@jpl-vax
cc: STORK@mit-mc, info-cpm@brl
In-reply-to: Msg of 12 Jan 1984 1555 PST from Bruce L. Conroy <BLC at jpl-vax>

I warn you: use of DR CP/M Function 37 "reset disk" can be
hazardous to your disk directory.  The exact sequences that can
trigger the bug are not known; but it exists, it's real, it
jumps out and bites you, and you cannot know that it won't since
we don't know how it does it.

You are warned.


16-Jan-84 09:58:49-MST,1468;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:58:38-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  16 Jan 84 6:36 EST
Date: 16 January 1984 05:15 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  My BIOS for the Ithaca Intersystems 2A.
To: MMOON.ES@parc-maxc
cc: ABN.ISCAMS@usc-isid, pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax, 
    capn@uw-vlsi, info-cpm@brl-vgr
In-reply-to: Msg of Fri 13 Jan 84 12:08 PST from MMOON.ES at PARC-MAXC.ARPA

under copyright and patent law, ideas and concepts are not
protectable, but specific implementtions are.

plaguarism can be brought in for sufficient similarities even
though the language is not identical: if plot and characters are
essentially the same, juries may and have found plagiarism.

Dunno if that helps.
    Date: Fri, 13 Jan 84 12:08 PST
    From: MMOON.ES at PARC-MAXC.ARPA
    To:   ABN.ISCAMS at usc-isid.ARPA
    cc:   capn at uw-vlsi.ARPA,
          pur-ee!uiucdcs!parsec!ctvax!uokvax!andree at ucb-vax.ARPA,
          info-cpm at brl-vgr.ARPA
    Re:   My BIOS for the Ithaca Intersystems 2A.

    Don't know the legaliteis, etc., but I know of no manufacturer who ever
    published pseudo-code.  Can we translate the particular impilmentation
    of an algorithm, then communicate it?  Can common sense guidlines work
    here?  Anyone with legal credentials listening?

    		MMoon.es

16-Jan-84 09:59:54-MST,954;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:59:49-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  16 Jan 84 6:36 EST
Date: 16 January 1984 04:58 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  BDOS Function 37 possible bug.
To: Tli@usc-eclb
cc: Info-Cpm@brl-vgr
In-reply-to: Msg of 14 Jan 1984  23:11-PST () from Tony Li <Tli at usc-eclb>

Dear Mr. Li:
	Perhaps you know best.
	Me, I will not use Fn 37; I have seen too many disk
directories trashed.
	Re: how, it is NOT triggered ONLY by writing to
improperly opened/closed files.  There is NO (known to me)
simple algorithm for preventing the fn 37 bug from biting you,
even taking meticulous care.  Or so say several sources I trust.
	You are welcome to continue using fn 37 with its
undocumented features.  My apologies for bringing up the
subject. 
	I really ought to know better by now.

JEP

16-Jan-84 10:04:15-MST,784;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:04:11-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 12:32 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  14 Jan 84 12:22 EST
Date: Sat 14 Jan 84 12:23:58-EST
From: Mark Becker <CENT.MBECK%MIT-OZ@MIT-MC.ARPA>
Subject: No January BYTE here either..
To: INFO-CPM@BRL.ARPA, INFO-MICRO@BRL.ARPA

In response to jpm@bnl'l s message, I haven't received January's issue
of Byte either (I'm in Maryland).

     BUT I SURE HAVE SEEN IT IN THE STORES!!  EVEN THE GIANT GROCERY
     HAS IT ON THE SHELF!!!

     Ah, for the days when being a subscriber meant you got your issue
before the stores or corner newstand did....

Mark
-------

16-Jan-84 10:05:45-MST,1025;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:05:40-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 13:34 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  14 Jan 84 13:20 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 14 Jan 84 10:14-PST
Date: 13 Jan 84 6:50:14-PST (Fri)
To: info-cpm@brl
From: decvax!duke!mcnc!pbr@ucb-vax
Subject: Re: Heath/Zenith microcomputers
Article-I.D.: mcnc.1923
In-Reply-To: Article <106@5941ux.UUCP>

	I have been waiting for a Heathkit computer that runs UNIX
ever since I heard about their UNIX software group in Benton Harbor.
Can anyone tell me *if* there is a UNIX/Heathkit system anywhere,
*why* there isn't one (if there isn't), and/or what those UNIX programmers
in Benton Harbor have been doing for the past three years!
	I suspect that there are such systems, but that most Heathkit
catalog readers will buy the Heathkit OS, if that is all they see in the
catalog.
16-Jan-84 10:06:56-MST,4171;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:06:45-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 13:44 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  14 Jan 84 13:33 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 14 Jan 84 10:24-PST
Date: 12 Jan 84 6:28:27-PST (Thu)
To: info-cpm@brl
From: decvax!duke!mcnc!ecsvax!mjg@ucb-vax
Subject: CP/M Disk Formats
Article-I.D.: ecsvax.1847

Help wanted on compiling CPM disk format data !
-----------------------------------------------

This is a follow up to my last follow up requesting help on
compiling a data base of cp/m disk formats. Because of the minimal
of response I wonder just how many CP/M users really KNOW what
their own disk format is. I am still trying to compile information
and have got quite a lot from other sources. So far I am up to
about 30 formats and am willing to share this with anyone who can
make a positive contribution.

I need information in one of the following forms:

1) A freshly formatted disk with a single reasonably sized text
   file on it. The file must be large enough to span at least 2
   tracks. This is sufficient to extract all the parameters below.
   After analyzing I will return the original untarnished!.

2) The alternative, if you can provide it is to provide me with
   the following data:

Computer Make and Model No.
Disk Size, 5 or 8 (or 3 1/4 or 3 1/2!) inch
Is the format one or two side
Single or Double Density?
No of tracks, e.g. 35,40,77,80 etc.
Sector Size in Bytes.
Physical sector sequence on the disk. This is needed for
    optimum formatting. 8 inch SS,SD for instance has the
    sectors numbered 1,2,3,4,5........26.
Sector translate table. This tells the bios when you ask
    for a given sector number what actual sector to give.
    8 inch SS,SD has a table that starts 1,7,13,.....
Directory offset. This tells CPM what track the directory is on.
Directory size in sectors, bytes and number of files.
Sectors per track.

Some of the above information is contained in a standard CP/M
DPB table in your BIOS in the following format, ( I will give the
numbers for standard SS,SD 8 inch as an example):

SPT 1A00  (no of equivalent 128 byte sectors/track)
BSH 03    (Block Shift = Log base 2 of block size in sectors)
BLM 07    (Block mask = no of 128 bytes in block - 1)
EXM 00    (Extent mask, relates disk size and block size)
DSM F200  (Highest block number on disk - 1 )
DRM 3F00  (No of entries in directory -1 )
ALO C000  (Each bit set in ALO represents 1 block in the directory)
CKS 1000  (No of 128 byte sectors in directory )
OFF 0200  (Directory offset in tracks)

>From the above the block size is 8 128 byte sectors or 1k, the directory
2 and occupies 16 sectors or 2 blocks with 64 entries max.
Note that 2 byte values are expressed least significant byte first.

If you dont know how to determine the parameters of your cpm
format here is a simple way using DDT or SID:

Run DDT or SID and enter the following:

         DDT                      SID
A100                       A100
100  MVI C,1F              100   LD  C,1F
102  CALL 5                102   CALL 5
105  RST 7                 105   RST 38

then type a period (.) to get out of the Assembler mode. What
you have just done is create a small CPM program which will
use your CP/M to find its own DPB (device parameter block). Run
the program by typing G100 and display the CPU registers by
typing X. The address of the DPB is in the HL register pair.
Type D and the address to display the contents of memory starting
at the beginning of the DPB and read off the first 15 bytes which
is the DPB for the currently selected drive.


Please reply to me here at ecsvax!mjg by computer mail, or
Mike Gingell, PO Box 51155, Raleigh, NC 27609 or by phone (out of
work hours 919-847-4779).

Regards to all CPM users out there wherever you are,

               Mike Gingell,
                   PO Box 51155
                      Raleigh NC 27609

                       ....ecsvax!mjg
16-Jan-84 10:07:09-MST,936;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:07:04-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 13:44 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  14 Jan 84 13:35 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 14 Jan 84 10:17-PST
Date: 11 Jan 84 19:34:34-PST (Wed)
To: info-cpm@brl
From: decvax!duke!mcnc!ncsu!ncrcae!jdg@ucb-vax
Subject: ISIS to CP/M copy program
Article-I.D.: ncrcae.1047

Does anyone know of an MDS to CP/M disk copy utility that is public
domain (free)? Both MDS and CP/M disks are single density IBM format.
Also, has anyone written an ISIS emulation program such that ISIS files
could be executed under CP/M. I know of at least one company that sells
such a program for about $80, but I don't know how well it works.

         -----Jim Griggers
              duke!mcnc!ncsu!ncrcae!jdg
16-Jan-84 10:08:29-MST,3840;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:08:17-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 13:55 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  14 Jan 84 13:49 EST
Date: 14 January 1984 13:52 EST
From: Eric Stork <STORK@mit-mc>
To: info-cpm@brl
cc: STORK@mit-mc, POURNE@mit-mc, W8SDZ@mit-mc

SUBJECT: RESETT for dBASEII; Function #37 of BDOS

A few days ago, I submitted to the net a trick for POKEing an ass'y
routine from dBASEII and a specific illustration that I had
successfully used to solve a problem for a friend's accounting
system.  The illustration POKEd a routine utilizing BDOS Function #37
(reset an individual disk) and then CALLed that routine with a RETurn
to the dBASE .CMD file.

Jerry Pournelle has vigorously warned against using BDOS function #37.
His warnings are reproduced below. For me, it worked. But Jerry may be right.

Two more points:
       1.  At the end of Jerry's warning notes, a note from
           Bruce Conroy suggesting an alternate way of
           resetting dBASEII disks.  I have not tried, but
           will next time I need this function.

       2.  If someone from DRI reads this and can shed more light on
           the validity of the concerns that Pournelle has about
           BDOS Function 37, I for one would be eager to know
           what he/she has to say.

Eric

**************************************************************
Date: 14 January 1984 04:35 EST
From: Jerry E. Pournelle 
Subject:  Use of dBase RESET function.

I warn you: use of DR CP/M Function 37 "reset disk" can be
hazardous to your disk directory.  The exact sequences that can
trigger the bug are not known; but it exists, it's real, it
jumps out and bites you, and you cannot know that it won't since
we don't know how it does it.

You are warned.


Date: 11 January 1984 06:07 EST
From: Jerry E. Pournelle 
Subject:  *** SOMEWHAT IMPORTANT on dBase2 **

Your RESETT fix for Dbase 2 uses CP/M function 37 Reset Disk.

DO NOT USE THAT FUNCTION.

Function 37 has a serous bug, undocumented, that can cause CP/M
to write over the directories OF ALL DISKS it can get at,
including the A: disk, hard disks, memory drive disks, etc.  We
do not know precisely what triggers the bug; it takes a
reasonably complex pattern of disk changes and resets; but it
DOES THE JOB.  I know of three casees in which 10 megaByte hard
disks had to have their files reconstructed sector by sector
because they were bitten by CP/M FUNCTION 37.
	You must use RESET SYSTEM even though that logs you on
to the A: drive (and takes longer).  I repeat, DO NOT USE
FUNCTION 37.  You will regret it if you do.

J E Pournelle


Date: 12 Jan 1984 1555 PST
From: Bruce L. Conroy 
Subject: Use of dBase RESET function.

     Although  there are some funny effects in dBase's RESET 
command I have found it to be 100% reliable under several 
versions of dBase if:

     a)   Any files on the disk to be changed are closed 
(this is merely good practice in any event,)

     b)   The disk is changed, then

     c)   The command RESET (not RESET B) is given.

     In particular, this sequence avoids the following 
anomolies:

     a)   RESET B or RESET B: or any similar command seems 
to have no effect whatever.

     b)   As long as a data file is open, there is an 
unpredicable amount of data in memory, which is not on disk. 
If the disk is changed at this point these data are lost, 
unless

     c)   There is a file of the same name on the new disk, 
in which case, the extra data are stuffed into that file,
resulting in the loss of the integrity of both data files.
**************************************************************

16-Jan-84 10:08:59-MST,872;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:08:53-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 15:20 EST
Date:     Sat, 14 Jan 84 14:59:51 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Using MDM717 with Cromemco CDOS

CDOS users: Get M7CD-1.ASM, the overlay for Cromemco systems.

After you overlay MDM717.COM using DEBUG, patch the following
locations to NOPs (binary zeros): 2A8F, 2A90, 2A91, 2A92.

This will disable the CP/M disk stat call function 1Fh which is
not implemented in the current version of CDOS.  The MDM717 DIR
function will then work, but will show 0k left on the disk.
That's livable, and certainly better than before when CDOS gave
an error message and jumped out of MDM717 to return to the system.
--Keith
16-Jan-84 10:09:46-MST,796;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:09:38-MST
Received: From Parc-Maxc.ARPA by BRL-VGR via smtp;  14 Jan 84 18:26 EST
Date: Fri, 13 Jan 84 12:08 PST
From: MMOON.ES@PARC-MAXC.ARPA
Subject: Re: My BIOS for the Ithaca Intersystems 2A.
In-reply-to: <[USC-ISID]12-Jan-84 13:55:15.ABN.ISCAMS>
To: ABN.ISCAMS@usc-isid.ARPA
cc: capn@uw-vlsi.ARPA, pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax.ARPA, 
    info-cpm@brl-vgr.ARPA

Don't know the legaliteis, etc., but I know of no manufacturer who ever
published pseudo-code.  Can we translate the particular impilmentation
of an algorithm, then communicate it?  Can common sense guidlines work
here?  Anyone with legal credentials listening?

		MMoon.es


16-Jan-84 10:10:03-MST,966;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:09:58-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Jan 84 23:32 EST
Received: From Hi-Multics.ARPA by BRL via smtp;  14 Jan 84 23:27 EST
Date:  14 January 1984 22:25 cst
From:  Chan.HCSCAD@hi-multics
Subject:  Re: No January BYTE here either..
To:  Mark Becker <CENT.MBECK%MIT-OZ@mit-ml>
cc:  info-cpm@brl
In-Reply-To:  Message of 14 January 1984 13:42 cst from Mark Becker

I just got mine .  But I had the same problem last month (DEC issue) and
I actually called BYTE subscription.  The lady who answered my call said
that their policy is not to do anything until about 15 days after the
month (I forgot the exact number of days she said).  Call back after the
15th, in essential..  I have been thinking of canceling my subscriptin
and just go out to buy one on the 1st of every month.  Maybe we all
should do that.
16-Jan-84 10:10:36-MST,1473;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:10:29-MST
Received: From Sri-Nic.ARPA by BRL-VGR via smtp;  15 Jan 84 2:19 EST
Received: from USC-ECLB by SRI-NIC with TCP; Sat 14 Jan 84 23:18:24-PST
Date: 14 January 1984  23:11-PST (Saturday)
Sender: TLI@usc-eclb
From: Tony Li <Tli@usc-eclb>
To:   Info-Cpm@brl-vgr
Subject: BDOS Function 37 possible bug.
Reply-to: Tli@usc-eclb
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168


Hi,

You requested someone from DRI?  As far as I know, I'm the only one
from DRI who is on ARPA at all, much less reading Info-Cpm.

Anyhow, despite what Jerry Pournelle has to say, I know nothing of a
BDOS bug in function 37.  Now, you should realize that I'm probably
not the best person to ask.  I'm a summer intern at DRI, and as such,
don't deal with CP/M-80 to any extent.  So if there is a bug, there is
a VERY good chance that I wouldn't know about it.  

A better idea:  Is there anyone who reads this list who works for an
OEM who buys stuff from DRI?  If so, said person could holler at his
sales rep/tech support person from DRI.  

If this doesn't work, I do have some alternate methods for getting an
exact answer, but they're somewhat rash, and I'm reluctant to use
them.

Cheers,
Tony Li ;-)
Software Engineer
Systems Software Group
Digital Research Inc.

aka 
Tony Li <Tli@Usc-Eclb>
Univ. of Southern Ca.
16-Jan-84 10:14:11-MST,867;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:14:07-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 6:34 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  16 Jan 84 4:57 EST
Date: 16 January 1984 05:00 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  No January BYTE here either..
To: Chan.HCSCAD@hi-multics
cc: info-cpm@brl, CENT.MBECK%mit-oz@BRL.ARPA
In-reply-to: Msg of 14 Jan 1984 22:25 cst from Chan.HCSCAD at hi-multics

The problem is the Post Office, which in Dec/Jan treats BYTE
like a catlogue, which, I suppose, it resembles...
	We make more from copies sold in stores than from subs
(I think, I may be wrong there; marketing doesn't talk to
contributing editors much).  But heck, I can't even get copies
sent first class on time.  Sigh.

JEP

16-Jan-84 10:19:55-MST,865;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:19:52-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 8:53 EST
Received: From Nosc-Cc.ARPA by BRL via smtp;  16 Jan 84 8:37 EST
Received: by Nosc.ARPA (4.12/4.7)
	id AA06672; Mon, 16 Jan 84 05:39:49 pst
Date: Sun, 15 Jan 84 09:59:50 pst
From: bang!bblue@nosc
Message-Id: <8401161339.AA06672@Nosc.ARPA>
To: ksproul@rutgers
Subject: BREAK
Cc: info-cpm@brl, info-micro@brl

Keith, unfortunately, zok@ucb-vax is right about the break, even though
he called it a character.  The Anchor XII will not send the space state
required as a break, even when the space state is correctly sent to it
by the serial interface.  I tried it on that modem because I didn't believe
it at first either!  May I echo his sentiments...

16-Jan-84 11:53:17-MST,554;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 11:53:14-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  16 Jan 84 12:50 EST
Date:     Mon, 16 Jan 84 12:35:06 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Tli@usc-eclb
cc:       Info-Cpm@brl-vgr
Subject:  Re:  Function 37

Tony - I was very surprised to see that you consider it the responsibility of
the BIOS to detect a disk-change.  I should think that would be an OS
chore.  Comment ?


Dave
towson@amsaa

16-Jan-84 12:29:16-MST,635;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 12:29:13-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 13:40 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  16 Jan 84 13:22 EST
Date: Mon, 16 Jan 84 09:37 PST
From: MMOON.ES@PARC-MAXC.ARPA
Subject: Re: January Byte
In-reply-to: "jpm@bnl.ARPA's message of 14 Jan 84 00:59:54 EST"
To: jpm@bnl.ARPA
cc: info-cpm@brl.ARPA, info-micro@brl.ARPA

Know of 1 OC resident who got his 13-Jan; haven't checked our tech lib
yet, but mine's not here.  Microsystems is also late.

		MMoon.es


16-Jan-84 13:10:16-MST,2087;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 13:10:04-MST
Received: From Sri-Nic.ARPA by BRL-VGR via smtp;  16 Jan 84 14:22 EST
Received: from USC-ECLB by SRI-NIC with TCP; Mon 16 Jan 84 11:21:59-PST
Date: 16 January 1984  11:17-PST (Monday)
Sender: TLI@usc-eclb
From: Tony Li <Tli@usc-eclb>
To:   Jerry E. Pournelle <POURNE@mit-mc>
Cc:   Info-Cpm@brl-vgr
Reply-to: Tli@usc-eclb
Subject: BDOS Function 37 possible bug.
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168
In-reply-to: The message of 16 Jan 1984 04:58 EST from Jerry E. Pournelle <POURNE @ MIT-MC>

    Date: 16 January 1984 04:58 EST
    From: Jerry E. Pournelle <POURNE @ MIT-MC>
    To:   Tli @ USC-ECLB
    cc:   Info-Cpm @ BRL-VGR
    Re:   BDOS Function 37 possible bug.
    Return-path: <POURNE@MIT-MC>
    Received: from MIT-MC by USC-ECLB; Mon 16 Jan 84 01:59:12-PST

    Dear Mr. Li:
    	Perhaps you know best.

As I stated directly in my first comment.  I DO NOT KNOW BEST.  I DO
NOT KNOW CP/M-80 EVENT TO THE EXTENT THAT THE READERS OF THIS LIST DO.

    	Me, I will not use Fn 37; I have seen too many disk
    directories trashed.

You may be right.  If indeed there is a bug, I would like to know
about it.  Bugs should be common knowledge.  When DRI finds out about
a bug, it publishes a small in-house sheet, and then considers it a
feature.

    	Re: how, it is NOT triggered ONLY by writing to
    improperly opened/closed files.  There is NO (known to me)
    simple algorithm for preventing the fn 37 bug from biting you,
    even taking meticulous care.  Or so say several sources I trust.

May we talk to the sources?  I'm sure that the net would appreciate
more info on the problem.

    	You are welcome to continue using fn 37 with its
    undocumented features.  My apologies for bringing up the
    subject. 
    	I really ought to know better by now.

Yup, you're right.  We've argued before Jerry, and we've never gotten
anywhere but flaming.

Cheers,
Tony ;-)
16-Jan-84 13:15:53-MST,1341;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 13:15:46-MST
Received: From Sri-Nic.ARPA by BRL-VGR via smtp;  16 Jan 84 14:24 EST
Received: from USC-ECLB by SRI-NIC with TCP; Mon 16 Jan 84 11:23:54-PST
Date: 16 January 1984  11:20-PST (Monday)
Sender: TLI@usc-eclb
From: Tony Li <Tli@usc-eclb>
To:   David Towson (CSD) <towson@amsaa>
Cc:   Info-Cpm@brl-vgr
Reply-to: Tli@usc-eclb
Subject: Function 37
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168
In-reply-to: The message of Mon 16 Jan 84 12:35:06 EST from David Towson (CSD) <towson@amsaa>

    Date: Mon, 16 Jan 84 12:35:06 EST
    From: David Towson (CSD) <towson@amsaa>
    To:   Tli@usc-eclb
    cc:   Info-Cpm@brl-vgr
    Re:   Function 37
    Return-path: <towson@amsaa>
    Received: from AMSAA by USC-ECLB; Mon 16 Jan 84 09:37:31-PST

    Tony - I was very surprised to see that you consider it the
    responsibility of
    the BIOS to detect a disk-change.  I should think that would be an OS
    chore.  Comment ?

Hi Dave,

As you must realize, detection of a disk-change is actually a hardware
function.  The little microswitch on the disk drive door is usually
the mechanism.  It is, of course, up to the BIOS to pass this along to
the OS.  

Cheers,
Tony ;-)
16-Jan-84 13:26:59-MST,523;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 13:26:56-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 14:26 EST
Received: From Usc-Eclb.ARPA by BRL via smtp;  16 Jan 84 14:14 EST
Date: 16 Jan 1984 1110-PST
From: Dick <MEAD@usc-eclb>
Subject: DRC's Solid State Disk query
To: info-cpm@brl

Has anyone used the Digital Research Computers 256k S-100 Solid State Disk??
Any comments pro/con? Bugs? Compatibility problems?
-------
16-Jan-84 14:03:26-MST,668;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 14:03:17-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 15:08 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  16 Jan 84 15:02 EST
From: dgilbert.es@PARC-MAXC.ARPA
Date: 16 Jan 84 11:59:12 PST
Subject: CP/M Fn 37?
To: INFO-CPM@brl.ARPA
cc: DGILBERT.ES@PARC-MAXC.ARPA


Having not used function 37, I have a dumb question.  Are we only
talking about MP/M or CP/M86 systems when referring to fn. 37?
David Cortesi, in 'INSIDE CP/M' says fn. 37 is for MP/M only, not
CP/M 2.2.  Is David wrong about this too???


Doug.
16-Jan-84 14:04:36-MST,732;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 14:04:31-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  16 Jan 84 15:16 EST
Date: Mon 16 Jan 84 13:16:11-MST
From: Keith Petersen <KPETERSEN@SIMTEL20.ARPA>
Subject: New VAX/VMS XMODEM program
To: Info-Cpm@BRL-VGR.ARPA

XMODEM.FOR for VAX/VMS has been updated to XMODEM2.FOR in the SIMTEL20
MICRO:<CPM.VAXVMS> directory.  Thanks to Charles Horn and Dennis Recla
for the fix which repairs a bug in the command line search when the
R mode is used.  If there was an S in the extension then it would
try to send a file instead of receive.  Previously it searched for
the S command first.
--Keith
-------
16-Jan-84 15:35:31-MST,945;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 15:35:27-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  16 Jan 84 17:01 EST
Date:     Mon, 16 Jan 84 16:47:20 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Tli@usc-eclb
cc:       David Towson (CSD) <towson@amsaa>, Info-Cpm@brl-vgr
Subject:  Re:  Function 37

Tony - It is my understanding that CP/M-80 detects a disk change by
noting that the directory information that has been read from the "first"
disk no longer matches the information read from the "second" disk, and that
when this happens we get the familiar (although usually unwelcome) message
"BDOS ERROR R/O", and the system must be reset.  Is this not so ?

Second question:  If a given drive does have the door switch, and I want
to have my BIOS pass the information from this switch to CP/M, what
should the BIOS put where ?


Dave

16-Jan-84 15:49:46-MST,1730;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 15:49:41-MST
Received: From Sri-Nic.ARPA by BRL-VGR via smtp;  16 Jan 84 17:15 EST
Received: from USC-ECLB by SRI-NIC with TCP; Mon 16 Jan 84 14:13:41-PST
Date: 16 January 1984  14:08-PST (Monday)
Sender: TLI@usc-eclb
From: Tony Li <Tli@usc-eclb>
To:   David Towson (CSD) <towson@amsaa>
Cc:   Info-Cpm@brl-vgr
Reply-to: Tli@usc-eclb
Subject: Function 37
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168
In-reply-to: The message of Mon 16 Jan 84 16:47:20 EST from David Towson (CSD) <towson@amsaa>

    Date: Mon, 16 Jan 84 16:47:20 EST
    From: David Towson (CSD) <towson@amsaa>
    To:   Tli@usc-eclb
    cc:   David Towson (CSD) <towson@amsaa>, Info-Cpm@brl-vgr
    Re:   Function 37
    Return-path: <towson@amsaa>
    Received: from AMSAA by USC-ECLB; Mon 16 Jan 84 13:57:58-PST

    Tony - It is my understanding that CP/M-80 detects a disk change by
    noting that the directory information that has been read from the "first"
    disk no longer matches the information read from the "second"
    disk, and that
    when this happens we get the familiar (although usually unwelcome) message
    "BDOS ERROR R/O", and the system must be reset.  Is this not so ?

I think that that's exactly correct.  Just one question:  How often
does CP/M-80 read the directory?  I don't know.  As I said, I'm not an
expert on CP/M-80.

    Second question:  If a given drive does have the door switch, and I want
    to have my BIOS pass the information from this switch to CP/M, what
    should the BIOS put where ?

I don't know.  I haven't done it.

Cheers,
Tony ;-)

16-Jan-84 17:54:01-MST,440;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 17:53:57-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 19:36 EST
Received: From Mit-Ml.ARPA by BRL via smtp;  16 Jan 84 19:36 EST
Date: 16 January 1984 19:34 EST
From: Herb Lin <LIN@mit-ml>
Subject:  PD programs  to do file compares...
To: info-cpm@brl



are there any?  names, etc?


tnx.

16-Jan-84 19:17:01-MST,1702;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 19:16:51-MST
Received: From Dec-Marlboro.ARPA by BRL-VGR via smtp;  16 Jan 84 20:58 EST
Date: 16 Jan 1984 2052-EST
From: "Ted Hess" <THESS@dec-marlboro>
To: Tli@usc-eclb, towson@amsaa
cc: Info-Cpm@brl-vgr
Subject: Re: Function 37
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11984195593.16.555.24503 at DEC-MARLBORO>
Regarding: Message from Tony Li <Tli@usc-eclb> of 16-Jan-84 1708-EST

Folks - CP/M-80 & CP/M-86 will read a directory whenever:

1) You open a file

2) Close a file

3) Do a directory operation like delete, rename etc...

4) The first disk i/o performed (on each drive) after "warm boot","disk reset",
   or ^C (which causes warm boot).

5) Every time you do I/O to a file across a 16K boundary (ie 16K := 1 extent).
   NOTE: No matter what block size or disk organization you use, this is one of
   CP/M's natural (and most inefficient) constants.

Oh yes, CCP/M gets around this by using an LRU disk cache and expecting
the BIOS to inform it that a drive door changed state. The unfortunate
fact about this feature is that it is very difficult to flush these
buffers from inside an application. It seems that CCP/M won't flush the
buffers and mark them invalid if there are any files open on that drive.
The problem, I suppose is to prevent a disk change while a file is open,
however, I don't think anything is being gained by preventing an
application from trying to guarantee all the data it has modified
(including the directory itself), be up to date!

Sorry, didn't mean to flame CCP/M - It's really quite nice.
					/ted
   --------
16-Jan-84 19:38:43-MST,1702;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 19:38:32-MST
Received: From Dec-Marlboro.ARPA by BRL-VGR via smtp;  16 Jan 84 21:10 EST
Date: 16 Jan 1984 2052-EST
From: "Ted Hess" <THESS@dec-marlboro>
To: Tli@usc-eclb, towson@amsaa
cc: Info-Cpm@brl-vgr
Subject: Re: Function 37
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11984195593.16.555.24503 at DEC-MARLBORO>
Regarding: Message from Tony Li <Tli@usc-eclb> of 16-Jan-84 1708-EST

Folks - CP/M-80 & CP/M-86 will read a directory whenever:

1) You open a file

2) Close a file

3) Do a directory operation like delete, rename etc...

4) The first disk i/o performed (on each drive) after "warm boot","disk reset",
   or ^C (which causes warm boot).

5) Every time you do I/O to a file across a 16K boundary (ie 16K := 1 extent).
   NOTE: No matter what block size or disk organization you use, this is one of
   CP/M's natural (and most inefficient) constants.

Oh yes, CCP/M gets around this by using an LRU disk cache and expecting
the BIOS to inform it that a drive door changed state. The unfortunate
fact about this feature is that it is very difficult to flush these
buffers from inside an application. It seems that CCP/M won't flush the
buffers and mark them invalid if there are any files open on that drive.
The problem, I suppose is to prevent a disk change while a file is open,
however, I don't think anything is being gained by preventing an
application from trying to guarantee all the data it has modified
(including the directory itself), be up to date!

Sorry, didn't mean to flame CCP/M - It's really quite nice.
					/ted
   --------
16-Jan-84 20:26:36-MST,603;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 20:26:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 22:13 EST
Date:     Mon, 16 Jan 84 22:10:31 EST
From:     Rick Conn <rconn@brl>
To:       Herb Lin <LIN@mit-ml>
cc:       info-cpm@brl
Subject:  Re:  PD programs to do file compares...

The ZCPR2 utilities COMPARE and DIFF are for file compare.  COMPARE
simply tells you if two files are the same, and DIFF lists differences
in decimal, hex, and ASCII.  SIMTEL20 has these in the ZCPR2 archives.

Rick
17-Jan-84 08:50:41-MST,558;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:50:37-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 23:14 EST
Received: From Cmu-Cs-A.ARPA by BRL via smtp;  16 Jan 84 23:13 EST
Date: 16 Jan 84 2310 EST (Monday)
From: George.Wood@cmu-cs-a
To: jpm@bnl, info-cpm@brl
Subject: Re: January Byte
In-Reply-To: "MMOON.ES@PARC-MAXC.ARPA's message of 16 Jan 84 12:37-EST"
Message-Id: <16Jan84.231006.GW90@CMU-CS-A>

My Jan. Byte's not here either. Dr.Dobbs is, though.
17-Jan-84 08:50:50-MST,788;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:50:44-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  16 Jan 84 23:25 EST
Date:     Mon, 16 Jan 84 23:25:30 EST
From:     Keith Petersen <w8sdz@brl>
To:       Herb Lin <LIN@mit-ml>
cc:       Info-Cpm@brl-vgr
Subject:  Re:  PD programs to do file compares...

COMPARE.COM compares any CP/M files and aborts when it comes to a difference.
DF.COM compares two ASCII files and prints the differences to the console.
HEXDIF.COM compares any two CP/M files (binary or ASCII) and prints the
addresses and the byte values in HEX and ASCII (if printable).  All are
available on SIMTEL20.  Get MICRO:<CPM>CPM.CRCLST for a complete listing
of what's available.
17-Jan-84 08:51:01-MST,1271;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:50:55-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  17 Jan 84 0:11 EST
Date: 17 January 1984 00:10 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Function 37
To: towson@amsaa
cc: Tli@usc-eclb, Info-Cpm@brl-vgr
In-reply-to: Msg of Mon 16 Jan 84 16:47:20 EST from David Towson (CSD) <towson at amsaa>

It is not required that you RESET the system if the BIOS is
properly written, but you will have to do a ^c warm boot if you
have changed disks; R/O actually means that the bit map doesn't
match t he current directory entries.
	As to BIOS detecting door opening, on 5 1/4" disks there
is no hardware detect is there?  Nor do I know a way to detect
whether a door HAS BEEN OPENED although you can have (and my
BIOS does) a look at the door to see if it is open NOW and put
up a message like "Load Drive A" or "Please close Door" or some
such; I recall startling some Morrow and Compupro troops a
couple of years ago by inviting them over to the house and
showing them I could access non-existent disks, open doors, or
anything else, and recover from it.
	But that was before fn 37, which can have unrecoverable
errors.

17-Jan-84 08:51:11-MST,469;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:06-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  17 Jan 84 0:24 EST
Date: 17 January 1984 00:23 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  BDOS Function 37 possible bug.
To: Tli@usc-eclb
cc: Info-Cpm@brl-vgr
In-reply-to: Msg of 16 Jan 1984  11:17-PST () from Tony Li <Tli at usc-eclb>

Please continue to use the feature.

17-Jan-84 08:51:21-MST,959;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:16-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  17 Jan 84 0:27 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  17 Jan 84 0:24 EST
Date: 17 January 1984 00:20 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  CP/M Fn 37?
To: dgilbert.es@parc-maxc
cc: INFO-CPM@brl
In-reply-to: Msg of 16 Jan 84 11:59:12 PST from dgilbert.es at PARC-MAXC.ARPA

CP/M 2.2  The confusion happens because many of the older CP/M
manuals, including alas the one distributed with Compupro CP/M
2.2 systems, stop with Function 36 and do not even mention
37-40.  Fn 37 returns a 0 in A to be compatible with MP/M

Incidenteally Tony installed CP/M 8/16 tonight with a new
Compupro hard disk.  I love it.  Huge TPA even with 8-bit stuff
since all the CP/M goo is in memory above 64K and the 8088
handles disk ops fast fast fast...

17-Jan-84 08:51:32-MST,719;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:27-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  17 Jan 84 0:34 EST
Date: 17 January 1984 00:32 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Function 37
To: Tli@usc-eclb
cc: Info-Cpm@brl-vgr
In-reply-to: Msg of 15 Jan 1984  23:36-PST () from Tony Li <Tli at usc-eclb>

wearily I repeat: under circumstances not known to me, but which
have happened to Systems Interface Consultants, Proteus
Engineering, and other correspondents, fn 37 can wipe out the
diredctory of a HARD (not removable) disk.  This is an
interesting feature.
	May you have many interesting features.

17-Jan-84 08:51:45-MST,1310;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:39-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  17 Jan 84 1:22 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  17 Jan 84 1:11 EST
Date: 17 January 1984 01:08 EST
From: Robert L. Plouffe <PLOUFF@mit-mc>
Subject: mdm716/mdm717 BUGS?
To: INFO-MODEM7@mit-mc, INFO-CPM@mit-mc, INFO-CPM@brl, INFO-MODEMXX@simtel20


1. "Mea Culpa" on stack imbalance at label MONIN:  Thanks to
Dick Mead for finding that one.   that got in there.

2. Data capture buffer is NOT affected by fifer size.
It uses all of memory up to the CCP or optionally can ehe CCP.  The 2k floppies.  16k of buffering does not buy anythingfile
transfer speed.  Try it both ways and you will see for yourseason for SECTORnot upsetting the protocol when a file transfer i
a remote that is under BYE and the 'Q' switch is not set so thatreporting is seethe ACKNAK flag and has nothing to do with ARPANEt
this is slightly different from the original CHRISTENSEN protocompletely compator upon a 10 sec timeout.

4.  Sorry for delay inall of the discue Country for 10 days and just
returned.

5. In vve discussion, arce code to give a 2k
file transfer buffer AND thCKNAK flag to penly (or timeout)..
17-Jan-84 08:51:57-MST,1899;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:50-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  17 Jan 84 1:23 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  17 Jan 84 1:18 EST
Date: 17 January 1984 01:15 EST
From: Robert L. Plouffe <PLOUFF@mit-mc>
Subject: mdm716/mdm717 bugs?
To: INFO-MODEM7@mit-mc, INFO-CPM@mit-mc, INFO-CPM@brl, INFO-MODEMXX@simtel20

1. "Mea Culpa" on stack imbalance at label MONIN:  Thanks to
Dick Mead for finding that one.  I don't know how that got in there.

2. Data capture buffer is NOT affected by file transfer buffer size.
It uses all of memory up to the CCP or optionally can even overwrite
the CCP.  The 2k size recommendation has to do with the slowness of
floppies.  16k of buffering does not buy anything with respect to file
transfer speed.  Try it both ways and you will see for yourself.

3. The reason for SECTOR_RESEND_ON_VALID_NAK only has to do with
not upsetting the protocol when a file transfer is being made FROM
a remote that is under BYE and the 'Q' switch is not set so that full
progress reporting is seen at both ends. Thus is the reason for killing
the ACKNAK flag and has nothing to do with ARPANET.  I realize that
this is slightly different from the original CHRISTENSEN protocol,
but it is completely compatible with it.  So in MDM716, repeats are
done only if a valid NAK is received or upon a 10 sec timeout.

4.  Sorry for delay in responding to all of the discussion of the
past week or so, but I was out of the Country for 10 days and just
returned.

5. In view of the above discussion, and if you use MDM717 as released
by HOFF, I recommend the you modify the source code to give a 2k
file transfer buffer AND that you set the ACKNAK flag to permit
resending of sectors upon receipt of valid NAK only (or timeout)..
17-Jan-84 08:52:08-MST,1103;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:52:03-MST
Received: From Mit-Multics.ARPA by BRL-VGR via smtp;  17 Jan 84 3:51 EST
Date:  Tuesday, 17 January 1984 03:48 est
From:  Schauble@MIT-MULTICS.ARPA
Subject:  Function 37 - disk door open
To:  info-cpm@BRL-VGR.ARPA, POURNE@MIT-MC.ARPA
Message-ID:  <840117084842.884899@MIT-MULTICS.ARPA>

Some disk drives (my Qume DT8's for example) have a "disk change" line
on the interface.  This is driven by a flip-flop that is set when the
door is open and reset when the drive is unselected while ready. If you
select the drive and find -ready, there is presently not a disk in it.
If you find it ready and disk change, someone changed the disk while you
weren't looking. 

I don't know about the existance of this feature on 5 inch disks. I do
know that the IO driver discriptions for MS/DOS document an entry point
for "is this disk changed since the last I/O operation" that can return
"yes", "no", or "I don't know". So I suspect that it occurs on 5 inch
disks also.
17-Jan-84 08:52:29-MST,815;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:52:22-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  17 Jan 84 3:58 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  17 Jan 84 3:56 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 17 Jan 84 0:39-PST
Date: 15 Jan 84 16:55:17-PST (Sun)
To: info-cpm@brl
From: harpo!eagle!mhuxl!aluxe!lra@ucb-vax
Subject: spell program in C
Article-I.D.: aluxe.1274


Does anyone have a public domain "spell" program written in 'C'?
I would like to put it up on my Apple with Aztec 'C'.

If one exists, would the kind person bless net.sources with it.  I'm
sure this would be of general interest.

		Thanks..

Lonnie R. Abelbeck
AT&T Bell Laboratories
..{mhuxh | aluxe}!lra
17-Jan-84 08:53:45-MST,958;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:53:41-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  17 Jan 84 8:51 EST
Date:     Tue, 17 Jan 84 8:42:08 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Ted Hess <THESS@dec-marlboro>
cc:       info-cpm@brl-vgr
Subject:  Re:  Function 37

Ted - Thanks for the information - very helpful.  One question:  What is an
LRU ?  In the equipment maintenance business, it means "line replaceable unit"
a term derived from "flight line".  It refers to any "box" that can be quickly
replaced in an aircraft standing on the flight line.  I doubt if that's what
you mean by "LRU disk cache".  By the way, as another bit of trivia, some folks
in the maintenance business take LRU to mean "least replaceable unit", which
is a small part, and is therefore the exact opposite of "line replaceable unit"
- very confusing.

Dave

17-Jan-84 08:54:43-MST,1392;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:54:36-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  17 Jan 84 9:22 EST
Date:     Tue, 17 Jan 84 9:14:55 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Jerry E. Pournelle <POURNE@mit-mc>
cc:       towson@amsaa, Tli@usc-eclb, Info-Cpm@brl-vgr
Subject:  Re:  Function 37


Jerry - Right you are.  When I said "reset the system" I was thinking of
"warm boot", not hardware reset; but I was too lazy to go back and edit the
message after I read it over and decided I'd used the wrong term.  In view
of all I am now typing, I'd have been way ahead if I'd edited the message.
Ah well, what the heck...  The BIOS I'm using (Omikron Mapper-I BIOS for the
TRS-80 Model-I) has a nice trap built in that allows "dignified" recovery
from an open door.  It displays the message "NOT READY TYPE C", and then waits
for you to close the door and type "C" (for "continue", I suppose).  However,
when you switch disks and then try to write to the new disk without doing
a warm boot first, it nails you with the familiar BDOS ERROR, and there is no
dignified way out.  I'd much prefer a nice friendly question like, "HEY DUMDUM,
do you REALLY want to do this ?", to which I could respond "Y" to continue or
"N" to abort.  Someday, I'll hack that in.

Dave

17-Jan-84 10:06:47-MST,2817;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 10:06:36-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  17 Jan 84 11:42 EST
Date:     Tue, 17 Jan 84 11:29:42 EST
From:     David Towson (CSD) <towson@amsaa>
To:       info-cpm@brl-vgr
Subject:  TAC news.

The following is provided for the benefit of those persons who can access
MILNET TAC's.

Dave Towson
info-cpm-request@brl-vgr

-----------------------------------------------------------------------------


Received: From Sri-Nic.ARPA by BRL via smtp;  16 Jan 84 19:51 EST
Date: Mon 16 Jan 84 16:04:23-PST
From: NIC
Subject: All-Points Broadcast--TAC Login Procedures
Sender: NIC@SRI-NIC
To: ALL-POINTS: ;
Reply-To: NIC@SRI-NIC

The following message explains MILNET TAC Login.  Users will encounter
the need for this information as of Midnight tonight EST.  These
instructions are also available through all MILNET/ARPANET TAC's as a
menu item in the TACNEWS system, which is accessible via the "@n"
command.  Note that ARPANET users will be unaffected at present,
unless they use a MILNET (Defense Data Network) TAC to access their
ARPANET host.

Please broadcast these TAC Login procedures to all of your MILNET TAC
users.  As announced in DDN Newsletter No. 35, the Universal UserID
procedure will be in effect 17 January through 15 February, after which
individual UserIDs will be necessary.

=====================================================================
The access control system for MILNET (Defense Data Network) TAC's
requires you to login before connections may be opened.  

The login  process is  automatically started  with the  first  "@open"
("@o") command  you  issue.  There  is  also a  new  "@logout"  ("@l")
command  to  logout.   Otherwise,  the  functioning  of  the  TAC   is
unaffected by the access control system.

Here is a sample of the login dialog  (user input is underlined):

a)	PVC TAC 110 #:01
b)      @o 26.2.0.8<RETURN>
	-----------
c)	TAC Userid: TAC.LOGIN<RETURN>
		    ----------
d)	Access Code: 22ockedc2<RETURN>		(Does not echo.)
		     ----------
e)	Login OK
f)	TCP trying...Open

In the above example, the TAC prints its greeting (a).  The user
proceeds to give the command to open a connection to host 26.2.0.8 (b).
If you are used to using a host number with a slash in it, you may
still use that form, i.e. "@o 2/8", as long as you are not going across
networks.  The TAC prompts for a TAC UserID. The user enters the Universal
UserID which expires February 15, 1984 (c).  The Access Code corresponding
to the UserID is entered (d).  After a brief wait, the TAC indicates that

***Error on net connection***

=== brl-vgr netread error from amsaa at Tue Jan 17 11:43:49  ===
17-Jan-84 10:28:58-MST,5686;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 10:28:36-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  17 Jan 84 11:53 EST
Date:     Tue, 17 Jan 84 11:29:42 EST
From:     David Towson (CSD) <towson@amsaa>
To:       info-cpm@brl-vgr
Subject:  TAC news.

The following is provided for the benefit of those persons who can access
MILNET TAC's.

Dave Towson
info-cpm-request@brl-vgr

-----------------------------------------------------------------------------


Received: From Sri-Nic.ARPA by BRL via smtp;  16 Jan 84 19:51 EST
Date: Mon 16 Jan 84 16:04:23-PST
From: NIC
Subject: All-Points Broadcast--TAC Login Procedures
Sender: NIC@SRI-NIC
To: ALL-POINTS: ;
Reply-To: NIC@SRI-NIC

The following message explains MILNET TAC Login.  Users will encounter
the need for this information as of Midnight tonight EST.  These
instructions are also available through all MILNET/ARPANET TAC's as a
menu item in the TACNEWS system, which is accessible via the "@n"
command.  Note that ARPANET users will be unaffected at present,
unless they use a MILNET (Defense Data Network) TAC to access their
ARPANET host.

Please broadcast these TAC Login procedures to all of your MILNET TAC
users.  As announced in DDN Newsletter No. 35, the Universal UserID
procedure will be in effect 17 January through 15 February, after which
individual UserIDs will be necessary.

=====================================================================
The access control system for MILNET (Defense Data Network) TAC's
requires you to login before connections may be opened.  

The login  process is  automatically started  with the  first  "@open"
("@o") command  you  issue.  There  is  also a  new  "@logout"  ("@l")
command  to  logout.   Otherwise,  the  functioning  of  the  TAC   is
unaffected by the access control system.

Here is a sample of the login dialog  (user input is underlined):

a)	PVC TAC 110 #:01
b)      @o 26.2.0.8<RETURN>
	-----------
c)	TAC Userid: TAC.LOGIN<RETURN>
		    ----------
d)	Access Code: 22ockedc2<RETURN>		(Does not echo.)
		     ----------
e)	Login OK
f)	TCP trying...Open

In the above example, the TAC prints its greeting (a).  The user
proceeds to give the command to open a connection to host 26.2.0.8 (b).
If you are used to using a host number with a slash in it, you may
still use that form, i.e. "@o 2/8", as long as you are not going across
networks.  The TAC prompts for a TAC UserID. The user enters the Universal
UserID which expires February 15, 1984 (c).  The Access Code corresponding
to the UserID is entered (d).  After a brief wait, the TAC indicates that
login is successful (e) and goes on to the normal connection sequence (f).

When you are entering your TAC UserID and Access Code:

  - A carriage return (indicated as "<RETURN>" in the example)
    terminates each input line and causes the next prompt to appear.

  - As you type in your TAC UserID and Access Code, it does not
    matter whether you enter an alphabetic character in upper or
    lower case.  In the typing of the TAC UserID, all lower case
    alphabetic characters echo as upper case.

  - The Access Code is not echoed in full-duplex mode.  An effort is
    made to obscure the Access Code printed on hardcopy terminals in
    half-duplex mode.

  - As an aid to correct reading of Access Codes, they have been
    designed so that they never contain a zero, a one, a "Q" or a
    "Z", because each of these characters resembles another.  So if
    you think you see one of these characters in your Access Code,
    you know it is really the letter "O" [oh], the letter "L" [el],
    or the number "2" [two].

  - You may edit what you type by using the backspace (Control-H)
    key to delete a single character.

  - You may delete the entire line and restart it by typing
    Control-U.  A new prompt will appear.

  - While entering either the TAC UserID or Access Code, you may
    type Control-C to abort the login process and return to the TAC
    command mode.  You must interrupt or complete the login process
    in order to issue any TAC command.

After both the TAC UserID and Access Code are collected from the
terminal, the TAC must verify the login attempt.  Often this takes less
than a second, but in some cases a slight delay will occur.  Anything
typed at the terminal after the concluding carriage return of the
access code, but before the login confirmation (or denial) is received,
will generate the message "Wait" on the terminal.  If the login is
allowed, you will see the message "Login OK" and immediately afterward
the TAC will attempt to open your TCP connection.  If the login is
denied for any reason, you will see the message "Bad Login."  The TAC
will then prompt you for another UserID and Access Code.  After several
bad login attempts, the TAC will attempt to hang up your TAC port.

Once logged in, your port remains logged in as long as you have an open
connection.  There is a ten minute period after you close one
connection in which you may open another one without having to go
through the login sequence.  When you are finished using your TAC port
you should log out by using the TAC "@logout" command.  Typing "@reset"
has no effect on your login state.  If ten minutes go by during which
your port does not have an established TCP connection, the TAC will
attempt to hang up on your port, logging you out.

If you are having problems logging in, call the Network Information
Center at (415) 859-3695 between the hours of 8:00-17:00 PST.
-------

17-Jan-84 10:36:35-MST,802;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 10:36:30-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  17 Jan 84 12:05 EST
Date: 17 Jan 1984  10:04 MST (Tue)
Message-ID: <WANCHO.11984361659.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@simtel20>
To:   INFO-CPM@brl-vgr
Subject: M7P1-1.ASM - PMC Micromate Overlay for MDM7xx

Date: Monday, 16 January 1984  22:33-MST
From: wcwells%ucbopal.CC at Berkeley (William C. Wells)
Re:   M7P1-1.ASM - PMC Micromate Overlay for MDM7xx

We have developed an overlay for use with the PMC MicroMate 101
microcomputer and Unix timesharing systems.

Bill Wells  WB6NLL
wcwells@Berkeley.ARPA
--------------------

The file is now in MICRO:<CPM.MODEM7> as M7P1-1.ASM.  --Frank
17-Jan-84 11:26:50-MST,1656;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 11:26:44-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  17 Jan 84 13:07 EST
Date: 17 Jan 1984  11:07 MST (Tue)
Message-ID: <WANCHO.11984373127.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@simtel20>
To:   INFO-CPM@brl-vgr
Subject: Function 37 (clue!)
In-reply-to: Msg of 16 Jan 1984  22:32-MST from Jerry E. Pournelle <POURNE at mit-mc>

At the extreme risk of prolonging this discussion, I'm surprised that
no one noticed Jerry's not-so-subtle clue in his last message:

     fn 37 can wipe out the diredctory of a HARD (not removable) disk.

Most, if not all BIOSes are set up with hard disk logical drives
having CKS set to ZERO.  This is a crude but somewhat effective way to
indicate to CP/M that the drive is fixed rather than removable, and
not to bother doing the checksum calculation/compare.  This would be
fine in a single-user environment, but potentially devastating in a
multi-user one.

Function 37 "RESET DRIVE" is actually misnamed.  It should have been
named "RESET WRITE PROTECT VECTOR", which write-enables the indicated
drives, as opposed to "resetting" them.  A subtle but significant
difference.  An unsynchronized Function 37, combined with the fact
that hard disk drive integrity via checksum is bypassed, will indeed
cause unpredicatable results.

The correct and safe sequence is:

Function 25: Return Current Disk (needed for Function 14 below)
Function 13: Reset Disk System (ends up selecting A)
Function 14: Select Disk (to reselect the original current drive)

--Frank
17-Jan-84 11:39:54-MST,2169;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 11:39:45-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  17 Jan 84 13:14 EST
Received: From Office-2.ARPA by BRL via smtp;  17 Jan 84 13:02 EST
Date: 17-Jan-84 09:55 PST
From: ACB.TYM@office-2
Subject: Function 37 ..sigh.
To: info-cpm@brl
Message-ID: <[OFFICE-2]TYM-ACB-3Y1NK>

I have tried to hold off, but I can resist no longer.  Jerry tries to share his 
experience (is that not what this forum is for) and he is dumped on.   Such 
activity keeps me from sharing some of my experiences.  I am implementing LRU 
disk caches in the BIOS and am lamenting over the inability of the BIOS to tell 
when to flush the cache.  It is very unfriendly to leave the directory tracks of
an old disk in the cache (the old disk can be kept whole by using a write 
through cache) when allocating new files on a new disk.

Most schemes that are safe (no explicit action required to insure integrity of 
disks) end up flushing the cache every warm boot because the BIOS cannot 
distinguish between the first disk selection after warm boot (innocent) and the 
first disk selection after a change (requires flush).  This is ok for long 
sessions in database applications but not good when in an edit, compile, test 
loop.  I would be interested in the experiences of others but wary of being 
assumed to be an idiot.

Judging from the volume of the reaction to the Function 37 remarks, there are a 
lot of people out there waiting to pounce an a cause.  Long live Function 37!  I
certainly won't use it until someone explain's Jerry's information.

By the way, how silly it is to see 22 lines of mail header just to see some 
joker ask whether anyone has received BYTE.  Darn! I guess I will get lectured 
about how, If I wanted to spend the time (or how utility "X" on system "Y" will 
solve the problem) I could write a program to filter the header.  If all that 
garbage were written on a Postal envelope, the mail never would be delivered.  I
am not interested in the Odyssey of such a foolish letter, only the author.

 

17-Jan-84 12:58:14-MST,2541;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 12:58:05-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  17 Jan 84 14:32 EST
Date:     Tue, 17 Jan 84 14:32:09 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
cc:       Info-Modem7@mit-mc
Subject:  MDM717 update news

---forwarded from the Sysop Clearinghouse RCPM---

Msg 241 is 10 line(s) on 01/14/84 from STEVE SANDERS
to ALL about MDM717.MOD

When trying to overlay MDM717 with the M7NM-2.ASM file
I found that the ORG of 0D00h was bad...After hunting
around, I found the new location should be:
 
                    ORG     0CDFh
 
I have changed M7NM-2.ASM accordingly and will be carrying
a copy called M7NM-3.ASM with the new ORG as stated.
 
            Steve Sanders


Msg 242 is 10 line(s) on 01/14/83 from RON FOWLER
to ALL about NO MORE MDM RELEASES!!!

  Apparently, Irv didn't get the word -- I'm making MAJOR
modifications to MDM7 and am totally unwilling to add any-
one else's belatedly.  If you don't want to be left behind
(I will release a version # ahead of yours if need be), then
WAIT until I get done.  I will be only a few more days.
  Among the new features will be a TYPE command, a RENAME,
enhanced DIR command, ZCPR2-style DU file specifications,
and several other things I'm not specifying (in case I don't
get to them all).  So please, read and heed.
                                   --Ron Fowler


Msg 243 is 16 line(s) on 01/15/83 from RON FOWLER
to ALL about MORE RE MDM720

  Re the previous messages about the phone number library:
I have changed the ORG back to 0D00H.  This was not done
indiscriminately; MDM720 will have a new configuraton block
located immediately after the phone # library (the whole
thing will be configurable, including the modem overlay,
with my newest version of MLOAD; ddt no longer necessary).
Hence, this area must stay firmly located, now and forever.
  (Fair warning; don't spend a lot of time changing phone #
overlay files back, you'll just have to do it again later).
  Please forgive the tone of this and the previous message;
I am a bit upset about the new release of MDM several days
after I posted a message here asking for a moratorium, but
I guess I'll get over it (I just hate to have to go back and
add Irv's 717 stuff to what is no longer a correct ante-
cedant.  Plus I have this funny feeling that Irv is about
to do a 718....).           --Ron

--end--
17-Jan-84 14:24:13-MST,865;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 14:24:10-MST
Received: From Ucla-Ats.ARPA by BRL-VGR via smtp;  17 Jan 84 16:04 EST
Date:           Tue, 17 Jan 84 12:56:29 PST
From:           Willard Korfhage <korfhage@ucla-ats>
To:             info-cpm@brl-vgr
Subject:        Function 37 - disk door open

   Floppy disk controller chips can check for an open door by monitoring
the sector hole sensor (the 1791 does this). If the chip doesn't receive
a pulse from the sensor within xx milliseconds of the last pulse, then it
knows the disk has stopped rotating, presumably because the door has been
opened. If I read the data sheet properly, the 1791 can send an interrupt
when this happens.
   This technique, of course, works for any floppy, regardless of size.

		Willard Korfhage
17-Jan-84 21:13:47-MST,2136;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 21:13:41-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  17 Jan 84 22:52 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  17 Jan 84 22:46 EST
Date: 17 January 1984 22:41 EST
From: Robert L. Plouffe <PLOUFF@mit-mc>
Subject: mdm716 buffer size
To: INFO-MODEM7@mit-mc, RGF@mit-mc, INFO-CPM@mit-mc, info-cpm@brl, 
    info-modemxx@simtel20



The following message from Keith Petersen correctly and
completely explains the reason for the 2k file transfer
buffer.  He assumed as I did that the data capture buffer
(even if started at the same point) and the file transfer
buffer had independent size limits - i.e, one set by the
BUFSIZ equate for filhe other set by
checking to see if either the CCP or BDOS (optiono be overwritten so that the whole TPA can be used
on a dynamic bture.  This is tER, it was changed
somewhere along the line and iprinter
buffer tfile 

transfer and data capture buffers to BUFSI BE
STRAIGHTENEDE OPTIMAL COMPROMISE AS EXPLAINED BY KEITH),
AND BUFFER ALLOWED T BUFFER (FIXED) [4K OUGHT TO BE 
ENOUGH].  If I ul correctly, Ron, and it will hopefully

be in MDM718.

In the mey thing that can at 16 as Hoff has done in MDM717.


Do make sure patching with Dr since MDM715, the program has
been larger than overlay patch fi----
Date: Wed, 11 Jan 84 21:40:07 EST
From: Keit at brl-bmd>
To::   Chan.CST at hi-multics, INFO-CPM at brl-vgr
Rin mdm716

Pleasr already have MDM717
"in progress" and we shouldorthcoming from hate to see all that good stuff that
Bob Plouffe ripped out" by Iike it".  That's how we lost the "retry
after tenamoung other thir the
protocol file transfer mode.  It does not al
capture mode. th slower disk systems which took so long writingut (and consequein the directory) that they lost the next sector 
from the senderabort.
The 2k buffer was chosen MANY versions bacam was
MODEM2) apeed
and the improvement in receiving speed by puers
into the bufs the
way Ward Christensen's old original MODEM p the
disk.
-----
17-Jan-84 21:31:40-MST,791;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 21:31:37-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  17 Jan 84 23:13 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  17 Jan 84 23:11 EST
Date: Tue 17 Jan 84 20:03:20-PST
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: MDM versions
To: w8sdz@BRL.ARPA
cc: info-cpm@BRL.ARPA

   The old MODEM series supported both CPM 1.4 and
later versionss. The MDM series does not support 1.4 and
does not state that in descriptions, causing a great waste
off time till I contacted Irv Hoff.
   If possible, could the revisers support 1.4? If not
this information should be in descriptive material. Could
this get forwarded to Ron Fowler?
LESLIE ZATZ
-------
18-Jan-84 09:28:56-MST,3356;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 18 Jan 84 09:28:46-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  18 Jan 84 0:37 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  18 Jan 84 0:30 EST
Date: 18 January 1984 00:27 EST
From: Robert L. Plouffe <PLOUFF@mit-mc>
Subject: mdm716/717 buffer size
To: INFO-MODEM7@mit-mc, RGF@mit-mc, info-cpm@brl, info-modemxx@simtel20



The following message from Keith Petersen correctly and
completely explains the reason for the 2k file transfer
buffer.  He assumed as I did that the data capture buffer
(even if started at the same point) and the file transfer
buffer had independent size limits - i.e, one set by the
BUFSIZ equate for file transfer, and the other set by
checking to see if either the CCP or BDOS (optionally) was
about to be overwritten so that the whole TPA can be used
on a dynamic basis for data capture.  This is the way that
the program always used to work. HOWEVER, it was changed
somewhere along the line and it now allows the printer
buffer to use the TPA dynamically and fixes both the file 
transfer and data capture buffers to BUFSIZ. THIS NEEDS TO BE
STRAIGHTENED OUT SO THAT THE FILE TRANSFER BUFFER CAN BE
SET TO 2K (THE OPTIMAL COMPROMISE AS EXPLAINED BY KEITH),
AND THE DATA CAPTURE BUFFER ALLOWED TO USE THE TPA WITH
A COMPROMISE SIZED PRINTER BUFFER (FIXED) [4K OUGHT TO BE 
ENOUGH].  If I understand the mail correctly, Ron Fowler
is working on this, or some variation, and it will hopefully
be in MDM718.

In the mean time, the only thing that can be done is to leave
the BUFSIZ equate set at 16 as Hoff has done in MDM717.


Do make sure to SAVE 69 after patching with DDT as Keith has
repeatedly warned because ever since MDM715, the program has
been larger than indicated in the overlay patch files.


Forwarded message:
------------------------
Date: Wed, 11 Jan 84 21:40:07 EST
From: Keith Petersen <w8sdz at brl-bmd>
To:   Charlie Strom (NYU) <strom at brl-bmd>
cc:   Chan.CST at hi-multics, INFO-CPM at brl-vgr
Re:   buffer size in mdm716

Please tell Irv Hoff that Bob Plouffe and Ron Fowler already have MDM717
"in progress" and we should have something forthcoming from them with
these fixes in about a week.  I'd hate to see all that good stuff that
Bob Plouffe put in MDM716 "stripped out" by Irv "because he doesn't
agree with it" or "doesn't like it".  That's how we lost the "retry
after ten errors" option, amoung other things.

On the subject of the 2k buffer size.  This is true ONLY for the
protocol file transfer mode.  It does not affect the terminal
capture mode.  It was done after NUMEROUS complaints from people
with slower disk systems which took so long writing the 16k buffer
out (and consequently closing that extent and opening the next
in the directory) that they lost the next sector and several tries
from the sender.  In many cases this caused the transfer to abort.
The 2k buffer was chosen MANY versions back (when the program was
MODEM2) as an acceptable compromise between disk access speed
and the improvement in receiving speed by putting the characters
into the buffer instead of writing every sector (which was the
way Ward Christensen's old origithe
disk.
--------------
End of forwarded message..
18-Jan-84 09:33:50-MST,692;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 18 Jan 84 09:33:46-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  18 Jan 84 8:29 EST
Date:     Wed, 18 Jan 84 8:28:07 EST
From:     Keith Petersen <w8sdz@brl>
To:       Leslie Zatz <ZATZ@sumex-aim.arpa>
cc:       Info-Cpm@brl-vgr
Subject:  Re:  MDM versions and CP/M 1.4

You said that MDM7 doesn't work with CP/M 1.4.  What is it that isn't
supported?  Does the program bomb?  I use it at work on CDOS, which is
based on CP/M 1.3.  It works fine.  Why are you still using 1.4?  2.2
has so many nice features most people I know have long ago upgraded to
it.
--Keith
18-Jan-84 09:34:06-MST,756;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 18 Jan 84 09:34:03-MST
Received: From Parc-Maxc.ARPA by BRL-VGR via smtp;  18 Jan 84 8:13 EST
Date: Wed, 18 Jan 84 08:10 EST
From: Damouth.Wbst@PARC-MAXC.ARPA
Subject: Re: Function 37 - disk door open
In-reply-to: "korfhage@ucla-ats.ARPA's message of Tue, 17 Jan 84
 12:56:29 PST"
To: Willard Korfhage <korfhage@ucla-ats.ARPA>
cc: info-cpm@brl-vgr.ARPA

" .  .  monitoring the sector hole sensor .  .  .  works for any floppy,
regardless of size ."

Sorry - not true.   You forget that some 5 1/4" drives are soft
sectored.  The Apple II drives are not only soft sectored, they don't
even use the once-per-revolution index hole.

/Dave

19-Jan-84 08:29:40-MST,1902;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 08:29:16-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  19 Jan 84 2:23 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  19 Jan 84 4:31 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 19 Jan 84 1:09-PST
Date: 18 Jan 84 7:14:34-PST (Wed)
To: info-cpm@brl
From: hplabs!hao!seismo!rlgvax!plunkett@ucb-vax
Subject: Demise of JRT Pascal
Article-I.D.: rlgvax.1576

-
JRT Systems, makers of the $29.95 JRT Pascal compiler, have filed Ch. 11
Bankruptcy.  For some time I have been reading various letters-to-editors
complaining that JRT was slow to respond to orders, if at all.  Other
complaints, most notably from J. Pournelle of Byte, mentioned that
JRT Pascal was not Standard, and that it was a shoddy piece of work,
viz., easily crashable.  Yet "a bargain at $29.95".

The pricing seems to have been its undoing.  JRT was flooded with orders
it could not handle, the revenue received is now shown to have been
insufficient to support the software firm, yet almost everywhere I
read reviews commending Mr. Tyson for the courage of pricing it at
$29.95; that it was a "steal" for the Pascal programmer.  It strikes
me as a foolish act of irresponsibility to price a compiler so low,
and somewhat negligent on the part of reviewers to be seduced by the
mere $29.95.  (One exception was Dr. Dobbs that rightly said it was
*not* a bargain regardless of price.)

If the reports of JRT developing a Modula-2 compiler are true, I hope
that they will invest alot more effort into the product, price it
accordingly, and price it to support their company in maintaining and
improving it.  And in filling orders promptly.

JRT has committed a disservice to the software industry with their
JRT Pascal.

Scott Plunkett
..seismo!rlgvax!plunkett
19-Jan-84 08:29:44-MST,1115;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 08:29:33-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  19 Jan 84 3:24 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  19 Jan 84 5:27 EST
Date: 19 January 1984 05:25 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Demise of JRT Pascal
To: hplabs!hao!seismo!rlgvax!plunkett@ucb-vax
cc: info-cpm@brl
In-reply-to: Msg of 18 Jan 84 7:14:34-PST (Wed) from hplabs!hao!seismo!rlgvax!plunkett at ucb-vax

1. JRT 2.+ was NOT a bargain at any price.
2. His 3.0 was, assuming you could get it; did you actually read
what I said?
3. Barry workman can make a profit (not large) with sales at
$35.00 per disk postpaid if he doesn't have large royalties to
pay.
4. Borland'd Turbo Pascal at $49.95 IS a bargain, and indeed is
pretty nifty; and t hey seem to be surviving and thriving.
5. Bookstores make a good living selling books at considerably
less than $39.95; at least some do.
	And they have high volume of sales, lots of inventory,
lots of items to stock, unlike JRT.

19-Jan-84 08:30:05-MST,1217;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 08:29:51-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  19 Jan 84 6:05 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  19 Jan 84 8:13 EST
Date: 19 January 1984 08:11 EST
From: Robert L. Plouffe <PLOUFF@mit-mc>
Subject: MDM717 ACKNAK BUG
To: INFO-MODEM7@mit-mc, INFO-CPM@brl, INFO-MODEMXX@simtel20
cc: PLOUFF@mit-mc

I had recommended that the ACKNAK flag be set to 'NO' in MDM17
as released by Irv Hoff so that sectors are repeated only upon
receipt of a valid NAK or a timeout occurs.  This works automatically
in MDM716 since I had killed the ACKNAK flag.  However Hoff tried
to restore it in MDM717 and did it wrong. Setting ACKNAK to 'NO'
has no effect (gives same as 'YES'). For those who have source and
need a correction, the following three lines at GETACK are wrong:
	LDA	AGETACK
	ORA	A
	JZ	ACKLUP
Change to:
	LDA	ACKNAK
	ORA	A
	JZ	GETACK1

Better yet, wait for MDM720 (and go back to
MDM716 in the mean time).  Ron Fowler is working on beta test
version of 720 now and will have this as well as all the buffer
discussion problems fixed plus new featyres..
19-Jan-84 08:42:22-MST,1898;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 08:42:16-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  19 Jan 84 7:45 EST
Date:     Thu, 19 Jan 84 9:45:29 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Kaypro BIOS list bug

The following is forwarded from CompuServe, courtesy Irv Hoff.
---



 #: 74332      Sec. 1 - General
Sb: #Kaypro Mystery Solved
    18-Jan-84  01:54:26
Fm: JACK CRENSHAW 72325,1327
To: All

Some time ago I reported a problem with the MDM711/Kaypro/Epson combina-
tion, in that the ^P print buffer dropped characters.  Periodically, the
subject has come up again, with Irv Hoff and Pete Holsberg trying hardest

to help me solve the problem.  I finally got around to looking at the
Kaypro BIOS, and as Pete suspected, there's a bug. The offending piece
of code is in the ROM, and goes:

     LISTST:  IN     1CH    	;GET SYSTEM PORT
              BIT    3,A   	;TEST PRINTER READY BIT
              RZ        	;THIS IS THE BUG
              MVI    A, 0FFH	;ELSE RETURN FF
              RET

Note that if the bit 3 is zero, the routine returns garbage in A. The
garbage is whatever is in port 1CH, which includes output as well as
input bits.  However, the zero FLAG is set properly, which is why BIOS
function 4 (LIST) works OK.  Ironically, if the programmer had used the
usual ANI insruction instead of the Z-80 fancy bit test, he would have
saved two bytes as well as get the right response.  The bug is in the
ROM, so can't be easily fixed. The patch is easy, though -  Change the
jump vector in the BIOS to:   JMP PATCH   and add:

     PATCH:  CALL    0FB65H	;call old bios entry
             RNZ		;OK unless its zero
             XRA     A		;else clear A
             RET		;that's all, folks

					- Jack Crenshaw
19-Jan-84 09:09:34-MST,465;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 09:09:30-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  19 Jan 84 8:11 EST
Received: From Usc-Isi.ARPA by BRL via smtp;  19 Jan 84 10:15 EST
Date: 19 Jan 1984 07:13:48 PST
From: METH@usc-isi
Subject: TECO for CP/M
To:   INFO-CPM@brl
cc:   METH@usc-isi

Is there such an animal?  Is it in the public domain??

Sheldon Meth
-------
19-Jan-84 19:57:03-MST,294;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 19:57:00-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  19 Jan 84 19:31 EST

***Error on net connection***

=== brl-vgr netread error from amsaa at Thu Jan 19 19:32:24  ===
19-Jan-84 20:23:53-MST,3814;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 20:23:43-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  19 Jan 84 19:42 EST
Date:     Thu, 19 Jan 84 21:35:09 EST
From:     David Towson (CSD) <towson@amsaa>
To:       info-cpm@brl-vgr, info-micro@brl-vgr
Subject:  A good deal on Shugart model 800 8-inch drives.

     I'll get to the disk drives in a moment, but first an anecdote:  Several
years ago when there was no such thing as an under-500-dollars printer, I went
to a microcomputer show at the Philadelphia Civic Center.  A small local
company named Selectronics had a booth there, and they were selling various
surplus items.  In front of the booth they had a large placard that advertised
the availability of five Texas Instruments Silent 700 series printers (without
keyboards) for $100 each (yep, one-hundred -- ridiculous).  Well, I walked past
that sign for many circuits of the Civic Center until I had just about seen all
I wanted to see there.  Finally, I decided to go see their el-cheapo printers.
I asked the guy at the booth what was the deal.  He said they were made by TI,
they worked, and they were cheap, and what else did I want to know.  I asked to
see one print.  He said okay and hooked up a keyboard.  I typed and it printed,
only the line feed didn't quite work right, so I asked to try another.  Well,
in time I had tried all five, and the guy said I'd had my fun and now it was
time to put up or buzz off (he didn't really say THAT).  I picked one and began
writing my check.  Now mind you, these things had been sitting there ALL DAY
with everyone apparently thinking they must be junk -- just as I was thinking.
By the time I had written my check, they were all gone.  It seems that I had
attracted a BIG CROWD of interested folks just waiting for some reason to think
the $100 printers were okay.  And as soon as that was taken care of, they 
really moved fast.  So that was my introduction to Selectronics.  Now on to the
disk drives...
     Back in August 1983 I saw an ad in "Microcomputing" in which Selectronics
offered new Shugart model 800 8-inch drives for $140 each (what, a $350 drive
for $140 -- ridiculous).  After 15 milliseconds contemplation, I called the
company and asked for the details.  Nothin to it -- new drives, no hookers, 
$140.  They also had "little used" (as in slightly, not small) ones for $100. 
I didn't pursue that one.  I bought one of the new ones, and when it arrived
shortly thereafter, it was just what they said: new, clean, functional.  By
December, I was having a yen for a second 8-incher (I run a modified TRS-80
Model-I, originally with two 5-inch drives.)  So I ordered a second 8-inch
drive.  It arrived in jig time and didn't work worth a hoot.  There appeared to
be massive sticky-friction in the worm-drive head positioner.  I called
Selectronics:  No problem, they'd send a new one, and I should return the one
I had.  Well, they sent two.  It seems that one was sent as soon as I called,
and then when the shipping person read the letter I enclosed with the returned
drive, he sent another.  Both of these work fine, and I will now return one of
them, collect.  So there you have it, an unsolicited testimonial.  These people
have good stuff, and they're really pleasant to deal with.  They are located at
1229 South Napa Street, Philadelphia, PA 19146, and their phone number is
(215) 468-4645.  The person with whom I've spoken on several occasions is
Al Meely.  If you're in the market for an 8-inch single-sided (Iforgot to 
mention that) drive, you really ought to check this out.
     No, he's not my uncle, a friend or anything else to me.  I'm just a VERY
satisfied customer.


Dave
towson@amsaa

19-Jan-84 21:04:18-MST,1497;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 21:04:14-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  19 Jan 84 20:31 EST
Received: From Hi-Multics.ARPA by BRL via smtp;  19 Jan 84 20:25 EST
Date:  19 January 1984 20:20 cst
From:  DSullivan.CSC_SDO@hi-multics
Subject:  How to mangle a disk.
To:  INFO-CPM@brl
cc:  Pourn@mit-mc

It doesn't matter if you use reset all drives (function 13) or reset
drive (function 37) the following will muck up files/directories etc
given enough disk requests.
 Step 1) open a file on drive X
 Step 2) open file2 on drive X
 Step 3) write data to file x (less than 16k)
 Step 4) reset the disk. Both function 13 or 37 will do the trick.
 Step 5) write data to file2, the data will be written over file1's
        allocated area.
 Step 6) close the files, and make the damage perminant.
 What happens is the FCB for file1 is given blocks from the free pool
(as kept by the allocation vector)  The reset causes the vetor to be
re-initialized to the old pattern.  The writes to file2 then use the
re-initialized map, and re-allocate to the same space as file1.  These
two files now share a common set of blocks on the disk. Read/write
either and it will impact the data of the other.
 Please note when you have a hard disk, even less checking is done, so
it is easier to mangle the disk esp with BIOS that have disk cashes that
keep parts of directories around.
19-Jan-84 21:12:35-MST,593;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 21:12:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  19 Jan 84 20:43 EST
Received: From Mit-Xx.ARPA by BRL via smtp;  19 Jan 84 20:41 EST
Date: Thu 19 Jan 84 21:26:11-EST
From: Ralph W. Hyre Jr. <RALPHW@MIT-XX.ARPA>
Subject: "?Public domain version of MODEM in Apple Pascal?"
To: info-cpm@BRL.ARPA

If there isn't one available, I would appreciate a pointer to the document
describing the protocol so I can write one.   Thanks.

					- Ralph Hyre
-------
20-Jan-84 08:45:59-MST,955;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 08:45:50-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 2:47 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  20 Jan 84 2:46 EST
Date: 20 January 1984 04:55 EST
From: Jonathan W. Platt <JWP@mit-mc>
Subject: TECO for CP/M
To: METH@usc-isi
cc: INFO-CPM@brl

     Yes there is one TECO that I know of that runs under CP/M.
It has the same command structures as standard DEC TECO.  It
could be considered as version 29 for the PDP-11.  I don't know
if it has been updated as DEC updates their own.

     Contact:

     Small System Design
     P.O. Box 4546
     Manchester, New Hampshire  03108
     (603) 432-7929

     They call it TED for Text EDitor.  I believe it's only missing
a few commands (EG is one missing) of the DEC version.  But it does
have everything else, including indirect files.

20-Jan-84 08:46:28-MST,771;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 08:46:19-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 2:58 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  20 Jan 84 2:53 EST
Date: 20 January 1984 05:01 EST
From: Jonathan W. Platt <JWP@mit-mc>
Subject: CP/M PLUS!
To: INFO-CPM@brl

    I really need some info about CP/M 3.x.  I sent a message dated
11 January 1984, 04:31 EST with some questions.  NO ONE has answered
it!  It regarded banking tables and drive selection.  Would somebody
please be kind enough (if they have the time) to answer this one user's
questions?

                    In advance appreciation,

                    Jonathan Platt (JWP@MIT-MC)

20-Jan-84 08:47:24-MST,705;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 08:47:14-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 3:30 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  20 Jan 84 3:27 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 20 Jan 84 2:25-PST
Date: 19 Jan 84 10:45:53-PST (Thu)
To: info-cpm@brl
From: ihnp4!ihuxn!geewhiz@ucb-vax
Subject: VAX/VMS XMODEM source?
Article-I.D.: ihuxn.511

Does anyone have a source for a XMODEM program for a VAX/VMS.  
If you have any information, please contact me. 
                                      312-979-7910
                                        Jerry
20-Jan-84 09:00:49-MST,472;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 09:00:45-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 8:25 EST
Received: From Wpafb-Info1.ARPA by BRL via smtp;  20 Jan 84 10:22 EST
Date: Fri, 20 Jan 84 10:22:34 EST
From: elder@wpafb-info1
Subject: CP/M VT100 Emulator?
To: info-cpm@brl

Does anyone know of a VT100 terminal emulator for a Z80 machine running
CP/M?  

-Greg
20-Jan-84 09:31:32-MST,1097;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 09:31:28-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 8:58 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  20 Jan 84 10:49 EST
Date: 20 Jan 1984 05:57-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re: "?Public domain version of MODEM in Apple Pascal?"
From: ABN.ISCAMS@usc-isid
To: RALPHW@mit-xx
Cc: info-cpm@brl
Message-ID: <[USC-ISID]20-Jan-84 05:57:17.ABN.ISCAMS>
In-Reply-To: The message of Thu 19 Jan 84 21:26:11-EST from Ralph W. Hyre Jr. <RALPHW@MIT-XX.ARPA>

Don't I remember an article or message coming over the net where Christensen
explained in detail his protocol?  Think I have it at home on the Toad's
hard disk, but not here, and don't remember the pointer.

Yell if no one else knows and I'll give it to you.

Regards,  (and YES, PLEASE -- if no one else has done it in Pascal for
Public Domain, I VERY MUCH need such a creature!  Could save you all
beaucoup tax dollars!)

David Kirschbaum
Toad Hall
(ABN.ISCAMS@USC-ISID)
20-Jan-84 10:44:59-MST,3025;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 10:44:51-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 10:03 EST
Received: From Brl-Voc.ARPA by BRL via smtp;  20 Jan 84 12:05 EST
Date:     Fri, 20 Jan 84 11:56:24 EST
From:     "Ferd Brundick (LTTB)" <fsbrn@brl-voc>
To:       ABN.ISCAMS@usc-isid
cc:       info-cpm@brl
Subject:  Re:  "?Public domain version of MODEM in Apple Pascal?"

Hi,

Since Toad Hall has also expressed interest in an Pascal Modem7, I am
sending a copy of my original reply to the list at large.

- - - - - - - - - -

There <IS> a modem3 program written in Apple (SCUD) Pascal.  The files
are on simtel20 in MICRO:<CPM.PASCAL> and the names are given below.
I've never used the program because I don't own an Apple, but I do have
the MODEM3.PAS file if you can't get it from simtel20 (I can get and send
you the other 2 files if you need them).  Anyway, below is the header
info from the main file.

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>

PROGRAM modem;
      {Written by Jack M. Wierda  Chicago Illinois
      This program is in the public domain.

      LANGUAGE: UCSD Pascal
      FILES:    MODEM3.PAS -- main program
                MDM3-Z80IO.Z80 -- serial line interface for Z80
                MDM3-8080IO.Z80 -- serial line interface for Intel 8080

      This program is basically a re-write in PASCAL of Ward Christensen's
Modem Program which was distributed in CP/M User's Group Volume 25. Identical
and compatible options are provided to allow this program to work directly
with Ward's program running under CP/M. One difference is that when sending
files the PASCAL or CP/M transfer mode must be selected. The PASCAL mode
transfers files between two systems running PASCAL, while the CP/M mode is
used when the receiving system is running CP/M. Basically the CP/M mode
provides the linefeeds required to make a PASCAL file compatible with CP/M.
When CP/M files are received they contain linefeeds, these can be deleted
using the editor to make the file compatible with PASCAL. CP/M files may also
contain tabs which the PASCAL editor does not expand.
      External assembly language routines are used to read the status, and read
or write the keyboard and modem ports. These routines are available as
separate files for the 8080 and Z80 processors. The port and flag definitions,
and the timing constant for the one second delay should be changed as required
for your particular hardware.
      The program has been tested with text files only, and may not work
correctly for code or other types of files.
      The PDP-10 mode transfers PASCAL files to a DEC SYSTEM-10 computer.}

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
20-Jan-84 13:16:01-MST,1306;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 13:15:56-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 12:48 EST
Received: From Amsaa.ARPA by BRL via smtp;  20 Jan 84 14:54 EST
Date:     Fri, 20 Jan 84 14:43:56 EST
From:     David Towson (CSD) <towson@amsaa>
To:       ihnp4!ihuxn!geewhiz@ucb-vax
cc:       info-cpm@brl
Subject:  Re:  VAX/VMS XMODEM source?

Jerry - The VAX/VMS modem programs are in the directory "micro:<cpm.vaxvms>
on Simtel20.  The listing for this directory is attached.  If you need help
in getting the files, post a request for assistance, and someone on the list
will help you.

Dave
towson@amsaa

---------------------------------------------------------------------------


Filename			Type	 Bytes	 Sectors     CRC

Directory MICRO:<CPM.VAXVMS>
CTOV.FOR.1			ASCII	  2821   23 =  17H  6408H
QIO.DCK.1			ASCII	   115    1 =   1H  A2B1H
VTOC.FOR.1			ASCII	  2730   22 =  16H  747AH
XMODEM.COM.1			ASCII	   563    5 =   5H  6AAFH
XMODEM.DOC.1			ASCII	   649    6 =   6H  D3A5H
XMODEM.HLP.1			ASCII	  3656   29 =  1DH  10A9H
XMODEM.MSG.1			ASCII	  2796   22 =  16H  FDAFH
XMODEM.NOTE.1			ASCII	  7157   56 =  38H  346AH
XMODEM2.FOR.1			ASCII	 29651  232 =  E8H  C3A4H
20-Jan-84 15:16:35-MST,1301;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 15:16:31-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 14:50 EST
Received: From Rochester.ARPA by BRL via smtp;  20 Jan 84 16:55 EST
Received: by sen.rochester (3.327.3N) id AA07628; 20 Jan 84 16:54:47 EST (Fri)
Received: by cay.Rochester (3.327.3N+) id AA00127; 20 Jan 84 16:51:03 EST (Fri)
Message-Id: <8401202154.7628@sen.rochester>
Date: 20 Jan 84 16:54:47 EST (Fri)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re:  VAX/VMS XMODEM source?
To: ihnp4!ihuxn!geewhiz@ucb-vax.ARPA, info-cpm@brl.ARPA

Two comments:
1) I have used the XMODEM in the Simtel libary and it works finewith one proviso: To make it work at 4800  or 9600 baud, we
had to give the command which increases the typeahead buffer
size on the VAX (something like "ALTBUF", I think).
For it to take effect, we then had to log off and back on.
There may be a better way to do it permanently,
but I think it requires system-administrator privileges.

2) There is an XMODEM written in C available from DECUS.
I have not used in myself, but the people at the University
of Rochester's Production Automation Project say it
works well.

Mike Ciaraldi
ciaraldi@rochester
20-Jan-84 18:08:15-MST,618;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 18:08:11-MST
Received: From Rand-Unix.ARPA by BRL-VGR via smtp;  20 Jan 84 17:40 EST
From: tp3!bridger@rand-unix
Date: Friday, 20 Jan 1984 16:23-PST
To: randvax!info-cpm@brl-vgr
Cc: bridger@BRL-VGR.ARPA
Subject: ?litepens and software

	What experience do list-readers have with light-pens on cp/m
(or other) systems? Recommendations for both hardware and software
would be welcome.  Also, pointers to applications notes for programming
6545 & 6845 controllers to support this device.
--bridger
20-Jan-84 19:30:33-MST,5128;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 19:30:09-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 18:52 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  20 Jan 84 20:53 EST
Date: 20 January 1984 20:52 EST
From: Eric Stork <STORK@mit-mc>
To: info-cpm@brl
cc: STORK@mit-mc

Subject:  BDOS Function 37

Since I started this discussion, I felt an obligation to try
to get to the bottom of the issue.  So I spent much of a day reading
and experimenting.  I think I now understand what Function 37
does and does not do.

Frank Wancho pointed out that Function 37 is misnamed.  It should
be called RESET WRITE PROTECT VECTOR, he said.  That is NOT the
same as RESET DRIVE, he emphasized.  He went on to suggest the
use of Function 13 as a correct and safe sequence, with associated
use of functions 25 and 14 to get back to the disk one started on.

Function 13 is OK if one can close ALL files.  But when one wants
to continue to work out of a file on Drive A:, one cannot really
reset ALL drives. That's necessary wehn one wants to change disks
in a drive that holds data for a program.  So Function 37 has a
legitimate use and seems OK if one is careful.

Others suggested that the trick is to close ALL files on the drive
to be reset before using Function 37.  Failing to do that can result
in overwriting files or directories.  But it seems that when all file
on the drive to be reset are closed, Function 37 can be safely used.

The most interesting thing that I demonstrated in my experiments is
that Function 37 does NOT reset the diskmap for the drive to be reset,
but that the diskmap for that drive is reset by the first file I/O
operation following function 37.  I do not have a hard disk, which
Jerry Pournelle and Frank Wancho said could easily be trashed by
Function 37, but maybe someone who does have a hard disk can try
the experiment (without writing to the hard disk, just checking
out the disk map) and let us know how it goes.  It should go OK,
from what I could figure out, but I can't be sure.

Eric.

For those who might want to repeat or expand my experiment, there
follows a short ASM file:

********************
* This is a test program
* to analyze the results of BDOS Function #37
*
* Assemble the program into a COM file, and put that on Drive A:.
* Put a disk with files on drive B:, and log it in with ^C.
* Then run this program (I call it TEST.COM) and when asked to do so,
*  put a different disk on Drive B:
*
* The bitmap (as bytes) starts a 0300h for the first disk, and at
*  0330h for the second disk.  I use Ward C.'s Q.COM to look at it,
*  invoking it as    Q @300    , and stopping the display with ^S 
*  or with ^C, so that I can compare the bytes.


bufbyts	equ	31	;this value is the number of GROUPS/8
			; on your disks.  The bitmap copnsists of
			; one bit for each group.  My system has
			; 243 groups. 243/8=30.375, or 31 when
			; we round up.  Change this value for your 
			; system.  If you have more than 384 groups,
			; you must increase the size of BUF1: and BUF2:
			; to hold them.

	ORG	100H
	MVI	c,14	;select logical disk
	MVI	e,1	;select disk B:
	CALL	5
	MVI	c,27	;get address of disk alloc vector
	call	5	;returns with [HL] pointing to first of a
			; block that holds the disk map

	LXI	D,BUF1	;
	MVI	c,bufbyts	;use [C] as counter
LOOP1:
	MOV	A,M	;get byte of data into [A]
	STAX	D	;and store it in BUF1
	INX	H
	INX	D	;bump the pointers
	DCR	C	;reduce the counter
	JNZ	LOOP1	;loop until done

	LXI	d,message
	MVI	c,9
	CALL	5
xx:	mvi	c,11
	CALL	5
	ORA	A	;0 if no char, FF if character typed
	JZ	XX

	MVI	c,37	;now do the individual disk reset function
	LXI	d,0000$0000$0000$0010B ;drive b:
	call	5

* ********** This is the key.  The first disk operation seems to
* read the diskmap.  Try running the program with the next three
* lines commented out -- you'll see that the two disk maps are
* the same, so function 37 alone does not reset the disk map.
	LXI	D,FCB
	mvi	c,15	;open file (find file, or erase file work also)
	call	5
*********************************************************

	MVI	c,27	;get address of disk alloc vector
	call	5	;returns with [HL] pointing to first of 'n'-byte
			; block with bitmap (31 for my system)

	LXI	D,BUF2	;
	MVI	c,bufbyts	;use [C] as counter
LOOP2:
	MOV	A,M	;get byte of data into [A]
	STAX	D	;and store it in BUF2
	INX	H
	INX	D	;bump the pointers
	DCR	C	;reduce the counter
	JNZ	LOOP2	;loop until done
	JMP	0000h	;and quit

message:
	DB	'Switch disk in B:, then type any key to continue ','$'

FCB:
	db	1	;drive b:
	db	'JUNK       '
	db	0,0,0,0	;extent, reserved, & records
	db	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0


	ORG 300h
BUF1:
	DB	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0	;plenty of extra space
	DB	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	DB	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

BUF2:
	DB	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	DB	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	DB	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

END

23-Jan-84 09:19:44-MST,831;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:19:23-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 23:24 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  21 Jan 84 1:28 EST
Date: 21 January 1984 01:28 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
To: STORK@mit-mc
cc: info-cpm@brl
In-reply-to: Msg of 20 Jan 1984 20:52 EST from Eric Stork <STORK>

let me know the results of your experiment.  Systems interface
just lost another hard disk to #37 this week; directory is dead.
I do not know if they closed all files and such as you suggest.
incidentally, there is zero warning on that in any document I
have read.
	we now avoid 37 as not worth the risk. perhaps you will
have different results.  I'd be interested in hearing.

23-Jan-84 09:19:47-MST,4278;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:19:34-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 23:25 EST
Date:     Sat, 21 Jan 84 1:30:32 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Area code 213 BBS changes

--forwarded from the Sysop Clearinghouse RCPM--

                  (818) Area Code Helper
                     January 17, 1983
		(2nd version by Kim Levitt)

On Jan. 7th, the  213 area code which used to cover most of 
Los Angeles  County  was spilt in two.   For the benefit of
those who are changing dialing menus or macros,  here  is a
list of the  former 213 prefixes which are now 818.  If you 
dial  one  of them without the 1-818,  for  the  next  nine 
months you will probably get connected, but you might get a
recording which may, (probably will),  keep your modem from
connecting.  After Oct. 1st, (or possibly sooner), you will
not be connected unless you dial the (818) area code.   The
prefixes which were changed are listed below.

     240-244   Glendale            246-247   Glendale
     248-249   La Crescenta        280-282   Alhambra
     284-289   Alhambra            300       Alhambra
     303       Monrovia            304       Pasadena
     307-308   Alhambra            330-339   Covina
     340-341   Canoga Park         342-345   Reseda   
     346-348   Canoga Park         349       Reseda
     350       El Monte            351       Sierra Madre
     352-353   Sunland-Tujunga     354       La Canada
     355       Sierra Madre        356       Pasadena
     357-359   Monrovia            360-368   San Fernando
     400       Pasadena            440-441   Pasadena
     442-444   El Monte            445-447   Arcadia
     448       El Monte            449       Pasadena
     500       Glendale            501       Van Nuys
     502       Glendale            504       Sun Valley
     505-506   N. Hollywood        507       Glendale
     508-509   N. Hollywood        570-573   Alhambra
     574       Arcadia             575       El Monte  
     576       Alhambra            577-578   Pasadena
     579       El Monte            700       Canoga Park
     701       Reseda              702-704   Canoga Park
     705       Reseda              706-707   Agoura
     708       Reseda              709-710   Canoga Park
     715-716   Canoga Park         717       Reseda
     760-766   N. Hollywood        767-768   Sun Valley
     769       N. Hollywood        780-789   Van Nuys
     790       La Canada           791-799   Pasadena
     810       Covina              812       Covina
     814       Covina              817       Covina
     840-843   Burbank             845-848   Burbank
     880       Canoga Park         881       Reseda
     882-884   Canoga Park         885-886   Reseda
     887-888   Canoga Park         889       Agoura
     890-899   San Fernando        901-908   Van Nuys
     912-915   Covina              917-919   Covina
     917-919   Covina              951       Sunland-Tujunga
     952       La Canada           953-954   Burbank
     956       Glendale            957       La Crescenta
     960-969   Covina              980       N. Hollywood
     981       Van Nuys            982       N. Hollywood
     983-984   Van Nuys            985       N. Hollywood
     986-990   Van Nuys            991       Agoura
     992       Canoga Park         993       Reseda
     994-995   Van Nuys            996       Reseda
     997       Van Nuys            998-999   Canoga Park

The above list was compiled from a listing published in the 
Santa Monica Evening Outlook, supplemented by several calls 
to General Telephone Information.   Any errors are probably 
caused by my poor proof reading.  (Prefixes  505,  780-789,
790 and 791-799 were omitted on first version of this list.
These additional prefixes were listed on page  A-80  of the
Pacific Telephone  June 1983  Los Angeles White Pages,  and
have been confirmed to be a part of the (818) area code.)

(Original version by Henry Dowst - KA6KNJ; revision on 1/17
by Kim Levitt, sysop of Hollywood RCPM/MBBS (213) 653-6398)

23-Jan-84 09:19:58-MST,775;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:19:53-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 23:36 EST
Date:     Sat, 21 Jan 84 1:38:20 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Need to contact RCPM Sysops

All RCPM Sysops who are on the Info-Cpm mailing please reply to me via
netmail so I can make up a list for distributing software update and
coordination information. Please only those who have access to the net,
because I will be sending out periodic notices via netmail to the list.
Thanks. Keith Petersen, W8SDZ

    Arpanet:   W8SDZ@MIT-MC   or  W8SDZ@SIMTEL20   or  w8sdz@BRL
    Usenet:    ...!duke!unc!brl-bmd!w8sdz
23-Jan-84 09:20:09-MST,1787;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:20:02-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 23:58 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  21 Jan 84 1:55 EST
Date: 21 January 1984 01:54 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  How to mangle a disk.
To: DSullivan.CSC_SDO@hi-multics
cc: POURN@mit-mc, INFO-CPM@brl
In-reply-to: Msg of 19 Jan 1984 20:20 cst from DSullivan.CSC_SDO at hi-multics

thanks; yet (and I have to rely on what others tell me for this)
I am told that using 13 is safe; I do know that we have done
what looks like what you describe with no bad consequences; the
BIOS checks for it.  One thing we do a lot is change disks while
fioles are in the text editor; this makes backup copies.  At one
time the system used to go to the A disk once, then stay with
the b; the double klunk was a bit slow, so Tony tried to
eliminate it by using 37; no disasters with us, but we did get a
hang conditin once.  He looked into it; then we installed the
program on MPM 8/16 systems, and there was a furious rewrite,
and now it klunks to the A disk, then to the logged on disk,
then the A gain, then writesd to the logged on. I ain't sure
what's happening, but it is completely bulletproof; not even
Alex can crash it and he can crash almost anything.
	It was then I was told that 37 could cause disasters,
and after I became sensitized to listen for fn 37 horror stories
I heard more; and now our wizards refuse to use 37; that is
about my last comment on the subject, since I am reporting what
others tell me, not what I really know.  I have tried to study
the documentation for those functions,a and they don't trell me
a lot.


23-Jan-84 09:24:24-MST,2251;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:24:16-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  21 Jan 84 11:30 EST
Date:     Sat, 21 Jan 84 13:32:46 EST
From:     Bob Bloom (TECOM) <bbloom@brl>
To:       info-cpm@brl
Subject:  more fat on the dbase reset fire

From my dBase II version 2.4 user manual:

RESET [<drive>]

The RESET command is used to reset the CP/M bit map after a 
diskette has been swapped.  Normally, if a diskette is swapped, 
CP/M will not allow writes to take place util after a warm or 
soft boot has taken place.

If <drive> is not specified, then the entire system will be 
reset.  Unfortunately, neithr dBase nor the operating system can 
detemine which diskettes you may have swapped and I/O errors may 
result if a disk that has open files is replaced.  If <drive> is 
specified, dBase  checks to see whether any of its files are open 
on that drive and will prevent I/O errors.  THE <DRIVE>-LESS FORM 
SHOULD THEREFORE NOT BE USED AND IS MAINTAINED FOR COMPATIBILITY 
REASONS ONLY.  [Emphasis mine.]  Do not swap and RESET the drive 
which contains the dBase system command files.

So, have you tried the RESET <drive> form vs. the vanilla RESET?

I'm interested because I'm currently involved in writting a 
hopefully saleable package that will require a disk reset.  Also 
note that one cannot reset a disk containing a .CMD file that you 
are running even if no actual swap is made.

I may also note that Ashton-Tate has been very helpfull when I 
call their service number.  (Have your REGISTERED serial number 
handy - they ask for it.)  Ask about the "Technical Reference 
Notes" and the "Technical Support Notes" - these give some hacker 
type information on some of the bugs that have been found and 
what to do about them.  No notes on the reset command though.

I've not had problems using the reset d: form - should I expect any?
I am carefull to close all files first, never reset disks with either
dbase or a running command file on it.  The usual routine is to reset
a floppy drive on a HD system in order to read/write back-up files
while within dbase command file.

bob bloom
23-Jan-84 09:24:35-MST,975;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:24:29-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  21 Jan 84 12:14 EST
Received: From Ucb-Vax.ARPA by BRL via smtp;  21 Jan 84 14:19 EST
Received: by UCB-VAX.ARPA (4.22/4.19)
	id AA28439; Sat, 21 Jan 84 11:17:54 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
	(4.13/4.10) id AA11683; Sat, 21 Jan 84 11:13:20 pst
Received: by D.CC.Berkeley.ARPA
	(4.13/4.10) id AA23884; Sat, 21 Jan 84 11:09:15 pst
Date: Sat, 21 Jan 84 11:09:15 pst
From: Phil Lapsley <jlapsley%D.CC@berkeley>
Message-Id: <8401211909.AA23884@D.CC.Berkeley.ARPA>
Arpa-Address: jlapsley%D.CC@Berkeley
To: info-cpm@brl
Subject: SMAL/80 comments, anyone?

     Does anyone have any comments on the SMAL/80 "pseudo"-assembly
language?  I have seen some advertisements for it and it looks pretty
good, but nothing beats feedback.

					Phil
				<jlapsley%D.CC@Berkeley>
23-Jan-84 09:29:46-MST,5890;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:29:31-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  22 Jan 84 23:24 EST
Date:     Sun, 22 Jan 84 23:17:09 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  MDM719 now available

MDM719, the latest version in the MODEM7 series, is now available
on SIMTEL20 in the MICRO:<CPM.MODEM7> directory and temporarily
on MIT-MC in the FJW; directory.  The file names are:

  On SIMTEL20            On MIT-MC
  MDM719.ASM             MDM719 ASM
  MDM719.COM             MDM719 COM  (ITS-Binary format)
  MDM719.HEX             MDM719 HEX
  MDM719.MSG             MDM719 MSG  (explains recent updates)
  M7NM-4.ASM             M7NM   4ASM (latest phone number overlay
                                      which also can configure file
                                      transfer buffer size)

It's not necessary to get the latest .ASM file.  Get the .HEX or
.COM file and use your present MDM7xx overlay.  Remember to SAVE 69
after patching because recent versions are larger than those explained
in the overlay patching instructions.

NOTE:	If using the phone number overlay to change
	the phone library numbers, be sure to use M7NM-4.ASM.
	(previous versions of M7NM will not work with
	this new version, as the file transfer buffer
	is now optional length, nominally set for 4k.)

CHANGES FOR MDM719
------------------
     Fixed Irv's error in GETACK routine which prevented the robust 
improvement (added by Bob Plouffe) from working.  Changed ACKNAK to NO 
so default will require valid NAK rather than non-ACK.  This is part of 
the robust improvements, NOT because of any special ArpaNet require-
ment.  Changed SHOWHEX to true for distribution version so users would 
have HEX and DECIMAL reporting while transferring files (most users 
have told me they prefer to see both).  Changed PMMI dialing pulse 
default to 10pps which most exchanges will accept.  (This can be set to 
other pulse rates in the user overlay).
			- Keith Petersen, W8SDZ


CHANGES FOR MDM718
------------------
     Code added to the auto-dial routine for the new Anchor 300/1200 
modem which are selling at discount houses for $270 or so.  Computer 
now beeps continuously anytime a connection is made to attract the 
operator's attention.  Made the file transfer buffer length separate 
from that of the ASCII capture buffer (which remains 16k, one file-
extent).  Although the file transfer buffer has been 16k for well over 
a year, some of the newer floppy disk systems are quite slow and 
timeout errors could occur.  The file transfer buffer size is set by 
default to 4k (32 records, 20H).  It can be set at assembly time if 
using the entire MDM718.ASM file, or can be set in a few seconds with 
DDT by changing byte 0CFFH.  The number library is now fully automatic 
to insure it always starts on a new page (such as 0D00H) regardless how 
much the auto-dial section is altered.  Now responds to either "single 
digit" result codes (some Hayes Smartmodem users leave SW2 set that 
way) as well as the normal "verbose" result codes.
 
     To change the file transfer buffer size via DDT, change byte 0CFFH:

		10   (hex)   =   16 records   =   2k
		20   (hex)   =   32 records   =   4k
		40   (hex)   =   64 records   =   8K
		60   (hex)   =   96 records   =  12k
		80   (hex)   =  128 records   =  16k

     (then SAVE 69 MDM.COM, etc.)


CHANGES FOR MDM717
------------------	
     MDM717 allows characters with parity bit set to be properly 
handled during propagation overruns after an X-off.  This occurs during 
a "save to disk" after the disk buffer fills.  (This problem was 
noticed on Compuserve which sends some characters with the parity bit 
set.)

     The disk buffer size was restored to 16k.  This is the length of 
"one file extent".  Even slow floppy disks can store 16k in a reason-
able amount of time.  This should remain 16k for distribution copies of 
the source code although it can be easily changed to suit the indivi-
dual user's own preference.  (It could even be lengthened to 32k if you 
like fewer disk operations.  This would make the printer buffer 
proportionally smaller but most printers are so fast the buffer is 
rarely filled in any case.)

     Fixed a stack problem introduced in v716 in the "V" flag routine 
to allow the user to show ASCII characters on the CRT during a file 
transfer.

     Fixed the "L" Logon feature so it should be consistent.  At times 
it would run away without waiting for the echo characters, thus not 
correctly displaying the Logon message.

     Restored the ACKNAK feature developed for the exclusive use of the 
ARPANET networking group.  When set normal ("YES") it resends a disk 
record after any NON-ACK character is received.  This has been the 
normal configuration for all RCPM systems using the XMODEM file 
transfer program.  When set "NO" for ARPANET use, it resends a record 
only after a NAK has been received.  Other characters are ignored.  
Some systems will resend a NAK after a 10-second TIMEOUT.  This slows 
things considerably, which allows the main frame time to recover if 
busy.  This tends to run the phone bill higher for RCPM use, but is 
necessary for ARPANET to prevent aborting the file transfer too quickly 
if the main frame is busy.  If a normal TIMEOUT sequence does attempt 
to abort the transfer with the ACKNAK equate set to NO, it will ask if 
you want to try again or abort.  (RCPM systems would have already timed 
completely out with 10 consecutive errors, making the question 
worthless and misleading.  ARPANET does not have a similar feature, and 
the user can manually force the transfer to continue.)
				- Irv Hoff
23-Jan-84 09:39:57-MST,1092;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:39:53-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  23 Jan 84 10:21 EST
Date:     Mon, 23 Jan 84 8:47:20 EST
From:     Keith Petersen <w8sdz@brl>
To:       Richard G Turner <rturner@brl>
cc:       Info-Cpm@brl-vgr
Subject:  Why MDM719 was released

Irv Hoff continues to ignore our requests for moratoriums.  He
irresponsibly issued an update which, in my opinion, was not fully
tested.  Rather than have a "broken" version out there, I elected to fix
his broken MDM718 and reissue it as MDM719 so we'd have something that
WORKS while we wait for Ron Fowler to finish Beta-testing his new super
modem program.  I'm sorry if this issuing of a new version upsets
anyone, but I've had it with Mr. Hoff's "ignore everyone else" attitude.
We on the Info-Modem7 mailing list tried to tell him about some bugs he
introduced in MDM717 when he "undid" some of Bob Plouffe's very nice
ruggedization of the program because he "didn't agree with it".
--Keith
23-Jan-84 10:37:10-MST,949;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 10:37:06-MST
Received: From Hi-Multics.ARPA by BRL-VGR via smtp;  23 Jan 84 12:14 EST
Date:  23 January 1984 11:14 cst
From:  Cargo.PD@hi-multics
Subject:  info-modem7
To:  info-cpm@brl-vgr

I am a beginning mdm7xx user (just got mdm716 working on my hardware).
I would like to be informed of the changes and the reasons for them. How
does on get on the info-modem7 newsgroup? If it is open to me I would
like to join. My attitude is to wait until the versions of mdm7xx become
stable before making a switch. My main concern has to do with the size
of the systems required. This is often not stated when people say how
great programs of this type are. Not that I don't appreciate the
wonderful job you are doing; I just don't want to waste resources by
pulling files I can't use.

..David S. Cargo (Cargo -at HI-Multics)
23-Jan-84 11:16:16-MST,992;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 11:16:11-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  23 Jan 84 12:41 EST
Date: Mon 23 Jan 84 10:42:14-MST
From: Keith Petersen <KPETERSEN@SIMTEL20.ARPA>
Subject: Using MDM719 with CDOS
To: Info-Cpm@BRL-VGR.ARPA


Date:     Mon, 23 Jan 84
From:     Keith Petersen, W8SDZ
To:       All
Subject:  Using MDM719 with Cromemco CDOS

CDOS users: Get M7CD-1.ASM, the overlay for Cromemco systems.

After you overlay MDM719.COM using DEBUG, patch the following
locations to NOPs (binary zeros): 2AB5, 2AB6, 2AB7, 2AB8.

This will disable the CP/M disk stat call function 1Fh which is
not implemented in the current version of CDOS.  The MDM719 DIR
function will then work, but will show 0k left on the disk.
That's livable, and certainly better than before when CDOS gave
an error message and jumped out of MDM719 to return to the system.
--Keith
-------
23-Jan-84 13:14:08-MST,1504;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 13:14:03-MST
Date:     Mon, 23 Jan 84 14:26:19 EST
From:     Dave Towson (info-cpm) <cpmlist@brl-vgr>
To:       info-cpm@brl-vgr
Subject:  Information needed.

I received the attached message from EDELHEIT@MITRE requesting information on
the availability of a Christensen-protocol program that will run on his main-
frames.  Knowing nothing about CMS, I have responded with information about
the Fortran programs in <cpm.vaxvms>, and the C programs in <unix.cpm>, both
on Simtel20, and the KERMIT programs (different protocol) on Columbia-20.  If
anyone has any other/better ideas please pas them along to Jeff with an info
copy to me so I'll know the answer if the question comes up again.  Thanks.


Date: 23 Jan 1984  0:34:49 EST (Monday)
From: Jeffrey Edelheit <edelheit@mitre>
Subject: Adding me to the distribution list and a communications question
To: info-cpm-request@mit-mc
Cc: edelheit@mitre


I own an Osborne 1.  It currently is a single density machine.
I have been using MODEM7 for communications, but have found that I can't
transmit files to either the C/70 or 4341, running CMS, that MITRE has
here.  Does anyone know of a program, preferably in the public domain, 
that will permit me to pass files from a CP/M machine to a larger, non-CP/M
host?  Virtually all the files I am attempting to pass are *.prn files.

Thanks,

Jeff Edelheit



23-Jan-84 13:57:39-MST,1203;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 13:57:34-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  23 Jan 84 15:21 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  23 Jan 84 15:13 EST
Date: 23 Jan 1984  12:08 PST (Mon)
Message-ID: <FHSU.11985968021.BABYL@WASHINGTON>
From: Sam <FHSU@WASHINGTON.ARPA>
Subject: looking for a micro around $300

I have a roomie who is looking at the TRaSh-80 color computer model 2.
Does anyone have any comments about whether this is a good starter system?
All he wants to do is to do text editing, formatting, and have a spelling
checker.  He also wants to attach an inexpensive printer (dot matrix?).  He
is looking to spend around $300-400 total.  Can anyone give me suggestions
and/or experiences?  He is a drama major, so a simple system will do.  He
is also looking at the Commodore VIC-20 or 64.  He has a TV, so if the
system wouldn't require a monitor, that'd be a plus.  I know there are
adaptors for monitor-to-TV, but I've have bad experiences with these.

Please reply to me directly, and I'll summarize for the nets if there are
others interested.  Thanks.

24-Jan-84 13:28:52-MST,907;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 13:28:47-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  24 Jan 84 14:41 EST
Received: From Rochester.ARPA by BRL via smtp;  24 Jan 84 14:27 EST
Received: by sen.rochester (3.327.3N) id AA22157; 24 Jan 84 14:31:18 EST (Tue)
Received: by cay.Rochester (3.327.3N+) id AA01846; 24 Jan 84 14:27:39 EST (Tue)
Message-Id: <8401241931.22157@sen.rochester>
Date: 24 Jan 84 14:31:18 EST (Tue)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: CP/M-86 Linker
To: info-cpm@brl.ARPA

Does anyone know of a CP/M-86 compatible linkage editor
which will produce a load map, showing where are the
library subroutines and other external names get relocated?
LINK-86 doesn't do this. It has a "MAP" option,
but it does not give this information.

Mike Ciaraldi
ciaraldi@rochester
24-Jan-84 13:41:02-MST,1883;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 13:40:53-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  24 Jan 84 14:58 EST
Received: From Rochester.ARPA by BRL via smtp;  24 Jan 84 14:44 EST
Received: by sen.rochester (3.327.3N) id AA22304; 24 Jan 84 14:37:41 EST (Tue)
Received: by cay.Rochester (3.327.3N+) id AA01865; 24 Jan 84 14:34:02 EST (Tue)
Message-Id: <8401241937.22304@sen.rochester>
Date: 24 Jan 84 14:37:41 EST (Tue)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: DRI C Compiler Woes
To: info-cpm@brl.ARPA

The new version of the Digital Research C compiler for
CP/M-86 is in. This is the first one to use their
new front-end/back-end technique.
It shares the back-end (code generator) with the Fortran 77
compiler, and has a different front-end (parser).

We received a letter in early December saying the new release
would be sent in mid-December. After Christmas we called to
ask where it was. They said we had to send in the form enclosed
with the letter. There had, naturally enough, been no form with the
letter, and no mention of a form in the letter.
DRI took the information over the phone (address, serial number, etc.,
all of which they knew already, since they had sent the letter
only to registered owners).

The first week in January we called again, and found they were not actually
shipping the update yet.

It arrived last week and has most of the old bugs.
Specifically, the floating-point I/O and floating-point to
integer conversions are all messed up. So, we are
using our own routines for these, which we had written
for use with the old release.

If anyone knows of a C compiler that runs under
Concurrent CP/M-86 and handles more than 64K of
data, we would appreciate knowing about it.

Mike Ciaraldi
ciaraldi@rochester  
24-Jan-84 13:45:17-MST,1031;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 13:45:11-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  24 Jan 84 14:56 EST
Received: From Rochester.ARPA by BRL via smtp;  24 Jan 84 14:36 EST
Received: by sen.rochester (3.327.3N) id AA22387; 24 Jan 84 14:40:06 EST (Tue)
Received: by cay.Rochester (3.327.3N+) id AA01869; 24 Jan 84 14:36:26 EST (Tue)
Message-Id: <8401241940.22387@sen.rochester>
Date: 24 Jan 84 14:40:06 EST (Tue)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Z-100 Concurrent CP/M
To: info-cpm@brl.ARPA

Zenith has still not sent the preliminary copy of Concurrent
CP/M-86 which they promised us for early December.
Latest rumor (which they have neither confirmed nor denied)
is that Digital Research is doing the port for them.
They are using the new version of CCPM, which includes the
GSX graphics package, windows, and MS-DOS compatibility.
So, it may be worth the wait.

Mike Ciaraldi
ciaraldi@rochester
24-Jan-84 13:46:25-MST,1080;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 13:46:20-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  24 Jan 84 14:58 EST
Received: From Rochester.ARPA by BRL via smtp;  24 Jan 84 14:46 EST
Received: by sen.rochester (3.327.3N) id AA22668; 24 Jan 84 14:49:12 EST (Tue)
Received: by cay.Rochester (3.327.3N+) id AA01893; 24 Jan 84 14:45:34 EST (Tue)
Message-Id: <8401241949.22668@sen.rochester>
Date: 24 Jan 84 14:49:12 EST (Tue)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re:  Byte finally showed up
To: info-cpm@brl.ARPA, info-micro@brl.ARPA, jpm@bnl.ARPA
Cc: jpm@BRL.ARPA

Mine showed up a while ago, but I was wondering if anyone else
has noticed something like this:

I see Byte on the stands one day. About a week later, people who
have subscriptions in Rochester start to get them,
and mine shows up about a week after that!

In other words, my copy is consistently among the last that arrive
in Rochester over a one-week span.

Mike Ciaraldi
ciaraldi@rochester
24-Jan-84 14:08:15-MST,947;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 14:08:10-MST
Received: From Rochester.ARPA by BRL-VGR via smtp;  24 Jan 84 15:05 EST
Received: by sen.rochester (3.327.3N) id AA23131; 24 Jan 84 15:06:00 EST (Tue)
Received: by cay.Rochester (3.327.3N+) id AA01940; 24 Jan 84 15:02:21 EST (Tue)
Message-Id: <8401242006.23131@sen.rochester>
Date: 24 Jan 84 15:06:00 EST (Tue)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re: writing w/o opening
To: Info-Cpm@brl-vgr.ARPA, w8sdz@brl.ARPA

Under MP/M, there is a checksum in the FCB.
This gets set when you open the file, and you cannot
read or write on the file unless this checksum is correct.
So, the problem of wiping out your directory by not
opening the file first should not occur.

I don't know if this technique is used in newer products
such as CP/M-86 or CP/M-Plus

Mike Ciaraldi
ciaraldi@rochester
25-Jan-84 12:34:45-MST,1009;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 25 Jan 84 12:34:40-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  25 Jan 84 8:08 EST
Received: From Jpl-Vax.ARPA by BRL via smtp;  25 Jan 84 7:57 EST
Date: 24 Jan 1984 2207 PST
From: Bruce L. Conroy <BLC@jpl-vax>
Subject: response to additional fat
To: info-cpm@brl
Cc: bbloom@brl
Reply-To: BLC@jpl-vax

With all deference to Ashton-Tate, I have never been able to
make the <drive> form of reset do anything. Here is a CMD file
which gives a BDOS EROR on B: R/O

* test of reset function
use b:dummy
list
use
reset b:
? 'change disk B and hit "return"'
wait
reset b:
create b:test
return

On the other hand, this CMD file performs as expected and so
far has never crashed a directory or even lost a bit of data.

* another test of reset function
use b:dummy
list
use
? 'change disk B and hit "return"'
wait
reset
create b:test
use b:test
list
return
------
25-Jan-84 16:49:42-MST,572;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 25 Jan 84 16:49:39-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  25 Jan 84 18:19 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  25 Jan 84 17:45 EST
Date: Wed, 25 Jan 84 13:01 PST
From: BillHolland.es@PARC-MAXC.ARPA
Subject: Re: SPELL and its DICT.DIC
In-reply-to: <[USC-ISID]12-Jan-84 14:03:31.ABN.ISCAMS>
To: ABN.ISCAMS@usc-isid.ARPA
cc: INFO-CPM@brl.ARPA

Where is Simtel20 and how can I download from there using my micro?

THANKS BILL

25-Jan-84 20:57:02-MST,874;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 25 Jan 84 20:56:59-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  25 Jan 84 22:36 EST
Received: From Mitre.ARPA by BRL via smtp;  25 Jan 84 22:35 EST
Date: 25 Jan 1984 22:27:58 EST (Wednesday)
From: Jeffrey Edelheit <edelheit@mitre>
Subject: Spell & spell.doc
To: billholland.es@parc-maxc
Cc: info-cpm@brl, edelheit@mitre


Simtel20 is at White Sands Missle Range.  For what machine are
you planning to use Spell on?  I have a copy of it for my Osborne
and I got it from my local users group.  Itt works fine, except
that II do not have a 3.0 release of wordstar, so I can't
use the automatic correction feature.

Re how do you download-try using tcp.

My question is, though, how are you going to get it to your pc?

Regards,
		Jeff



26-Jan-84 08:57:58-MST,945;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 08:57:53-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 1:24 EST
Received: From Uci-750a.ARPA by BRL via smtp;  26 Jan 84 1:13 EST
Date: 25 Jan 84 22:08:17 PST (Wed)
To: Mike Ciaraldi <ciaraldi@rochester>
cc: info-cpm@brl, info-micro@brl, jpm@bnl, jpm@brl, young@uci-750a
Subject: Re: Byte finally showed up
In-reply-to: Your message of 24 Jan 84 14:49:12 EST (Tue).
	     <8401241949.22668@sen.rochester>
From: Michal Young <young@uci-750a>

When I lived in Oregon, my Byte consistently showed up about one
week after it was on the newsstand.  (Since moving I haven't 
noticed when it hits the newsstands.)

The net traffic on this seems to indicate a lot of people dissatisfied
with Byte subscription service.  Is some concerted action appropriate?  
Any ideas?  

--Michal Young, young@uci
26-Jan-84 08:58:56-MST,969;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 08:58:52-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 3:15 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  26 Jan 84 3:05 EST
Date: Thu 26 Jan 84 00:09:30-PST
From: Dan Kent <KENT@SUMEX-AIM.ARPA>
Subject: Osborne to mainframe query, DSR sable?
To: info-cpm@BRL.ARPA

I'm  relatively new O-1 user, trying to talk to a DEC 2060 through a Vadic
VA3451 modem.  I'd like to set the DSR (pin 6 on the O-1's RS232 port) to
OFF when I'm just home computing, then toggle it ON (+5) when I load my
communications software, to wake up the modem.  As things stand now, the O-1
holds DSR high (+5), keeping the modem's DTR light on, and producing a scream
on the phone line when I'm home computing andgo to answer an ordinary incoming
ctel. call.       Can I do it?       Is this a general interest problem?

Dan Kent
-------
26-Jan-84 09:00:50-MST,1027;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:00:46-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 5:23 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  26 Jan 84 5:13 EST
Date: 26 January 1984 05:14 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject: help requested
To: INFO-CPM@mit-mc

I am doing an article for POPULAR on The Operating System
Jungle".  Part One is on the 8-bit micro world which is
dominated by CP/M (and Apple DOS).
	I would like to be as complete as is required, but I'm
not too familiar with many of the 8-bit rivals to CP/M.
	I'd appreciate SHORT info sketches of:
Turbodos
Oasis
	particularly if there are any enthusiasts for those out
there.  I have touched CDOS and TPM although if there's a TPM
enthusiast I'd apprecaited hearing about it's good points.  I've
mentioned the late unlamented TRS-DOS and its viable successor
L-DOS. What have I overlooked that's important?
Thanks,
JEP

26-Jan-84 09:00:59-MST,781;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:00:56-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 5:23 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  26 Jan 84 5:18 EST
Date: 26 January 1984 05:19 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Byte finally showed up
To: young@uci-750a
cc: ciaraldi@rochester, info-cpm@brl, info-micro@brl, jpm@brl, jpm@bnl
In-reply-to: Msg of 25 Jan 84 22:08:17 PST (Wed) from Michal Young <young at uci-750a>

well, one of you might write me at BYTE New Hampshire and I can
then (1) print that letter, and (2) m,ention the great whango of
othermail on the subject; t hat might cause something to be
done.  It might not, too.
JEP

26-Jan-84 09:04:06-MST,716;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:04:03-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 8:47 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  26 Jan 84 8:40 EST
Date: Thu 26 Jan 84 08:41:33-EST
From: Willie Lim <WLIM@MIT-XX.ARPA>
Subject: SPELL in C
To: info-cpm@MIT-MC.ARPA, info-micro@MIT-MC.ARPA

I am thinking of implementing Bill Ackerman's SPELL program in C for
my IBM PC.  He told that someone might have already done that.  Will
that someone please let me know who he is?  If no one has implemented
it in C, I'll probably write one and make it a public domain software.



Willie
-------

26-Jan-84 09:05:08-MST,1284;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:05:03-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 9:30 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  26 Jan 84 9:27 EST
Date: 26 Jan 1984 03:57-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re: Spell & spell.doc
From: ABN.ISCAMS@usc-isid
To: edelheit@mitre
Cc: billholland.es@parc-maxc, info-cpm@brl
Message-ID: <[USC-ISID]26-Jan-84 03:57:44.ABN.ISCAMS>
In-Reply-To: The message of 25 Jan 1984 22:27:58 EST (Wednesday) from Jeffrey Edelheit <edelheit@mitre>

Saw your msg on INFO-CPM.  I DO have Word* 3.0 -- AND SPELL from SIMTEL20.
WHAT auto-correction feature??

Also, re downloading to a PC - if the problem is moving binary files
(especially that DICT.DIC) through your data channels -- I solved that
(moving through an ornery TAC) with HEXIFYing it to ASCII, moving it down,
using Word* to break the HEX file up into memory-sized (about 40KB) segments,
MLOAD (or LOAD)ing it back to Binary, reassembling the resultant .COM
segments into a nice big DICT.DIC again at the micro, and then ITSCVTing
it to strip the ITS-binary header.  Worked just fine!  (Though what a kludge!)

Regards,

David Kirschbaum
Toad Hall
26-Jan-84 09:13:52-MST,1245;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:13:43-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 9:43 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  26 Jan 84 9:34 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 26 Jan 84 6:30-PST
Date: 24 Jan 84 8:39:31-PST (Tue)
To: info-cpm@brl
From:  ihnp4!houxm!hocda!hou3c!burl!clyde!akgua!psuvax!burdvax!bpa!ray@ucb-vax
Subject: mpx16 info wanted
Article-I.D.: bpa.213




	Just wondering, does anyone in netland own an MPX-16
from MicroMint?  Just wondered if they've got it running or
if there is anything I should look out for.  I've modified
mine up to rev and am waiting for the operating system. I ord-
ered the CPM-86, since I have 8" drives.  I was told by their
tech that I could not run the msdos with my shugarts.  I thought
there might be a way to modify it to support them, but I guess
not.  I'm kind of concerned about the CPM-86, since I'm not at
all familiar even with 8 bit CPM.  I'm sure this sounds naive
but can you run 8 bit CPM (8080) withe CPM-86? I thought it 
might be possible that you could.  Any info would be apprecia-
ted.


			Ray Benash
26-Jan-84 09:34:25-MST,1041;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:34:20-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 9:30 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  26 Jan 84 9:28 EST
Date: 26 Jan 1984 04:00-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re: Byte finally showed up
From: ABN.ISCAMS@usc-isid
To: young@uci-750a
Cc: ciaraldi@rochester, info-cpm@brl, info-micro@brl
Cc: jpm@bnl, jpm@brl
Message-ID: <[USC-ISID]26-Jan-84 04:00:47.ABN.ISCAMS>
In-Reply-To: The message of 25 Jan 84 22:08:17 PST (Wed) from Michal Young <young@uci-750a>

Can't STAND it any more...

I got my Byte in a timely fashion, about the same time I usually get it,
and before the newstands.

I live in North Carolina, which maybe affects delivery procedures and
schedules.  So here is no complaint.  (I am NOT criticizing those who did
NOT receive their Byte in a timely fashion, understand -- just that not ALL
had that problem.)

David Kirschbaum
Toad Hall
26-Jan-84 09:48:21-MST,872;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:48:18-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 10:36 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  26 Jan 84 10:27 EST
Date: Thu, 26 Jan 84 07:26 PST
From: TAFEL.pasa@PARC-MAXC.ARPA
Subject: Re: Byte finally showed up
In-reply-to: "young@uci-750a.ARPA's message of 25 Jan 84 22:08:17 PST
 (Wed)"
To: Michal Young <young@uci-750a.ARPA>
cc: Mike Ciaraldi <ciaraldi@rochester.ARPA>, info-cpm@brl.ARPA, 
    info-micro@brl.ARPA, jpm@bnl.ARPA, jpm@brl.ARPA, young@uci-750a.ARPA

I move that we all cancel our subscriptions and boycott the
turkeys!!!!!!
LETS TAKE A VOTE!!!!

AN UPRISING IS THE ONLY WAY TO COMBAT SUCH A TERRIBLE, DEHUMANIZING
(HUHHHH!) SITUATION!!!

UP IN ARMS

A RIOT!!!!!!!!!!!

Hugo.

27-Jan-84 11:12:40-MST,595;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:12:37-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  26 Jan 84 14:42 EST
Received: From Brl-Vgr.ARPA by BRL via smtp;  26 Jan 84 14:30 EST
Date:     Thu, 26 Jan 84 14:15:57 EST
From:     Ron Natalie <ron@brl-vgr>
To:       ABN.ISCAMS@usc-isid
cc:       young@uci-750a, ciaraldi@rochester, info-cpm@brl, info-micro@brl, jpm@bnl, 
          jpm@brl
Subject:  Re:  Byte finally showed up

Has anyone received their February Byte yet?

  o o
   ^
\_____/


27-Jan-84 11:14:48-MST,2600;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:14:39-MST
Date:     Thu, 26 Jan 84 17:00:39 EST
From:     Dave Towson (info-cpm) <cpmlist@brl-vgr>
To:       info-cpm@brl-vgr, steveh@mit-mc
Subject:  [Stephen C. Hill:  Stickyfying SIMTEL20]

I thought this was of sufficiently general interest to pass along to the list.


----- Forwarded message # 1:

Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  25 Jan 84 22:31 EST
Date: 25 January 1984 22:32 EST
From: Stephen C. Hill <STEVEH @ MIT-MC>
Subject:  Stickyfying SIMTEL20
To: info-cpm-request @ BRL-VGR
cc: STEVEH @ MIT-MC

Is there any method that can be used, while FTPing, that allows
one to not have to keep repeating MICRO:<CPM.xxxx> every time
that you GET a file or get a DIRectory listing?


----- End of forwarded messages



Steve - Here at Aberdeen Proving Ground, we are running a lot of UNIX systems.
This includes the machine from which info-cpm is distributed.  UNIX allows for
command-language programs, or shell-scripts, and  we have used this feature to 
good advantage in making the job of FTPing much simpler.  At present, this
system of programs is rather klugey, being composed of many bits and pieces that
all have to be available for the whole thing to work.  But work it does.  If I
type the command line "cpmug 029 sap.asm" it automatically calls simtel20 and
moves the file "micro:<cpmug.vol029>sap.asm" to a file having the name "sap.asm"
in the calling directory.  Using the editor, I can create a shell-script with 
entries on separate lines having the form "x program.name", and then use the
search-and-replace feature of the editor to substitute the string "cpmug 029" 
(adjust for different volume number) in place of "x".  That's fairly quick and 
easy to do.  Then if I mark the file just created as executable, I can run it
and move a whole batch of stuff automatically.  The main file-mover portion of
this kluge was written by Fred Brundick <fsbrn@brl-voc>.  It creates command
strings which are fed to FTP.  It uses several "subroutines", which are in  
separate files.  I've never added-up the number of different files that must be 
present to make what I've just described work, but it could easily be ten or so.
It's a real lashup - but it WORKS!  Fred is planning to make a nice civilized, 
all-in-one-hunk version someday, but it is now on the stack.  Other than this 
sort of approach, I don't know of any way to reduce the typing involved in
moving a bunch of files via FTP.


Dave

27-Jan-84 11:17:07-MST,2117;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:16:57-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 0:42 EST
Received: From Rochester.ARPA by BRL via smtp;  26 Jan 84 18:14 EST
Received: by sen.rochester (3.327.3N) id AA15956; 26 Jan 84 18:14:22 EST (Thu)
Received: by cay.Rochester (3.327.3N+) id AA05827; 26 Jan 84 18:10:49 EST (Thu)
Message-Id: <8401262314.15956@sen.rochester>
Date: 26 Jan 84 18:14:22 EST (Thu)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re:  Byte finally showed up
To: ABN.ISCAMS@usc-isid.ARPA, ron@brl-vgr.ARPA
Cc: info-cpm@brl.ARPA, info-micro@brl.ARPA, jpm@bnl.ARPA, jpm@brl.ARPA, 
    young@uci-750a.ARPA

1) I am happy to hear that at least someone gets his Byte in a timely fashion.
This has been bugging me for years, less so now that I get so many
magazines I can't read them all anyway.
About four years ago, I complained to Carl Helmers when he was in town.
He didn't seem very interseted, and just said, "We send them to the
Post Office",  ask them.
I called the Byte subscription number, and they said,
"We send them to the POst Office and the newsstands the same day,
so it must be the mail's fault."
I asked the Post Office, and they said it probably did not take 
two weeks to get from NH to NY every month.
2) Cancelling our subscriptions is somewhat like cutting
off noses to spite faces.


3) So, I suggest, we take a poll on when the, say February issue
shows up, then send the results to Byte, as J. Pournelle suggested.
Let's all be on the lookout for newsstand and subscription
copies. Has February Byte reached anyone yet?
What's on the cover?

Mike Ciaraldi,
ciaraldi@rochester

P.S. Every single person need not sennd mail. Maybe it shoukld
be tht the first one to see a newsstand copy in his or her
city should post, likewise the first sub,
then anyone who gets a sub copy more than a day or two later
could follow up with a message.
Hopefully, doing this ONCE will generate some statistics
without overloading the network.
27-Jan-84 11:17:28-MST,1200;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:17:23-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 3:19 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  27 Jan 84 3:15 EST
Date: 27 January 1984 03:19 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Byte finally showed up
To: ciaraldi@rochester
cc: ABN.ISCAMS@usc-isid, info-cpm@brl, info-micro@brl, jpm@brl, jpm@bnl, 
    young@uci-750a, ron@brl-vgr
In-reply-to: Msg of 26 Jan 84 18:14:22 EST (Thu) from Mike Ciaraldi <ciaraldi at Rochester.ARPA>

1> I have Feb BYTE sent to me FEDEX from teh printer; the
editorial people got theirs also same way same time.
2. They should NOW be in Post Office.  Understand: the darned
things are so big that only a couple of printers in the country
can hanle them. I believe the printer we now use does also Sears
roebuck catalogs.
3. St atistcs posted on this net will do NO good.  LETTERS to
the editorial office -- to me for that matter -- will POSSIBLY
get some attention, possibly not.
4. Cancelling subscription seems drastic.  Who does better on
getting out that much data so regularly?

27-Jan-84 11:18:25-MST,2562;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:18:17-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 3:41 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  27 Jan 84 3:29 EST
Date: 27 January 1984 03:33 EST
From: Herb Lin <LIN@mit-mc>
Subject:  multiple FTP gets from SIMTEL20 for CPM stuff..
To: cpmlist@brl-vgr
cc: STEVEH@mit-mc, info-cpm@brl
In-reply-to: Msg of Thu 26 Jan 84 17:00:39 EST from Dave Towson (info-cpm) <cpmlist at brl-vgr>

    From: STEVEH @ MIT-MC

    Is there any method that can be used, while FTPing, that allows
    one to not have to keep repeating MICRO:<CPM.xxxx> every time
    that you GET a file or get a DIRectory listing?

The way I automate this process is the following:

1. give FTP the SCRIPT command; this files away the terminal output
into a file of your choosing.  Call this file FOO.

2. do DIR MICRO:<CPM.xxxx>; this produces a directory listing in FOO.

3. edit FOO using the keyboard macro facility in EMACS to give the
appropriate lines.  Example:

FOO initially contains this:

dir micro:<CPM.filutl>   <- this is the command I issued
List started.		 <- this is what FTP tells me.
micro:<CPM.filutl>	 <- this is the name of the directory I asked about
compare.asm.20		 <- this is a file name in the directory.
sortv.asm.3		 <- this is a second file in the directory.

edit this file to look like this:

get mc:users2;COMP ASM	 <- get is the FTP command for getting a local
			    file.  MC:USERS2;COMP ASM is the file name
			    for the file you want to get.

micro:<cpm.filutl>compare.asm.20  <- COMPARE.ASM is the file name you
					want to get.

get mc:users2;SORT ASM		<- this is the local file name.

micro:<cpm.filtul>sortv.asm.3	<- SORTV.ASM is the second file you
					want.

The EMACS keyboard macro can be used to place the directory in front
of every desired file, and also to build the local file name from the
desired file name.  For example, on MC you can take the first six
characters of the first filename on SIMTEL and the last three
characters of the file type on SIMTEL.

Save the resulting file as BAR (For example)

4. LAST STEP.  issue to FTP the XFILE command.  This command takes a
command file and executes the contents just as though they were typed
in at the keyboard.

lemme know if I can help more.


Now, if only some version of MODEM would allow taking of files
received from a mainframe to a micro froma from a command file...


27-Jan-84 11:19:22-MST,1045;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:19:18-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 4:13 EST
Received: From Cmu-Cs-A.ARPA by BRL via smtp;  27 Jan 84 4:08 EST
Date: 27 Jan 84 0410 EST (Friday)
From: George.Wood@cmu-cs-a
To: ABN.ISCAMS@usc-isid, ciaraldi@rochester
Subject: Re: Byte finally showed up
CC: info-cpm@brl, info-micro@brl, POURNE@mit-mc
In-Reply-To: <[USC-ISID]26-Jan-84 04:00:47.ABN.ISCAMS>
Message-Id: <27Jan84.041012.GW90@CMU-CS-A>

Sorry; but I can't stand it either. It's January 26th and I STILL don't
have my January BYTE. JEP says the February issues have left the printers.

I think he missed the point about statistics: use the net for gathering
and reporting them to net users, and uSnail for reporting final results
to Byte, the post office, etc. But perhaps someone would volunteer to
accept all reports instead of clogging the net bb's, and compile a 
report at the end of the month.
					George
27-Jan-84 11:20:04-MST,1024;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:19:59-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  27 Jan 84 4:41 EST
Date: 27 January 1984 04:42 EST
From: Gail Zacharias <GZ@mit-mc>
Subject:  [Stephen C. Hill:  Stickyfying SIMTEL20]
To: cpmlist@brl-vgr
cc: STEVEH@mit-mc, info-cpm@brl-vgr
In-reply-to: Msg of Thu 26 Jan 84 17:00:39 EST from Dave Towson (info-cpm) <cpmlist at brl-vgr>

The FTP protocol has a CWD (change working directory) command.  Check the
documentation on your FTP program to see whether it provides an interface
to it.  For instance in TOPS-20 FTP you should be able to say
CWD MICRO:<CPM.FILUTL>
to change the default directory to micro:<cpm.filutl>.

If there is no such command in your FTP, or if it doesn't work, check if
there is a "quote" or "verbatim" command, which you can use to send CWD raw.
For instance in ITS FTP you should be able to say
QUOTE CWD MICRO:<CPM.FILUTL>
to get the same effect.

27-Jan-84 11:20:32-MST,1192;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:20:28-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 5:01 EST
Received: From Sri-Kl.ARPA by BRL via smtp;  27 Jan 84 4:48 EST
Date: 27 Jan 1984 01:49-PST
Sender: BILLW@sri-kl
Subject: Re:  multiple FTP gets from SIMTEL20 for CPM stuff..
From: BILLW@sri-kl
To: LIN@mit-mc
Cc: cpmlist@brl-vgr, STEVEH@mit-mc, info-cpm@brl
Message-ID: <[SRI-KL]27-Jan-84 01:49:51.BILLW>
In-Reply-To: The message of 27 January 1984 03:33 EST from Herb Lin <LIN@mit-mc>

Well, there is a set default directory command specified in the FTP
protocol, but it doesnt seem to work on many tops20 sites.

The name of the command also depends on your user FTP program.  The
CMU FTP uses CPATH, as in CPATH MICRO:<CPM.APPLE>  If your FTP does
not support an equivilent command, you can probably use a quote-like
command.  If simtel were up, Id test this out.  Oh well.

By the way, MODEM20 has had wildcard file transfers added to it,
and they almost work.  An option to take a list of files from
an indirect file would be easy to add.  Ill look into it.

BillW
27-Jan-84 11:21:44-MST,764;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:21:41-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 9:37 EST
Received: From Brl-Bmd.ARPA by BRL via smtp;  27 Jan 84 9:36 EST
Date:     Fri, 27 Jan 84 9:28:50 EST
From:     BRINT <abc@brl-bmd>
To:       Ron Natalie <ron@brl-vgr>
cc:       ABN.ISCAMS@usc-isid, young@uci-750a, ciaraldi@rochester, info-cpm@brl, 
          info-micro@brl, jpm@bnl, jpm@brl
Subject:  Re:  Byte finally showed up

Has anyone received his/her IEEE Transactions on Computers for November
or December, 1983?

I have received Scientific American for February, 1984.

The NY Times Book Review for 29 January 1984 arrived the other day.

27-Jan-84 11:22:15-MST,1034;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:22:11-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 9:48 EST
Received: From Utexas-20.ARPA by BRL via smtp;  27 Jan 84 9:41 EST
Date: Fri 27 Jan 84 08:41:24-CST
From: Kim Korner <CS.KORNER@UTEXAS-20.ARPA>
Subject: Re: Byte finally showed up
To: info-cpm@BRL.ARPA
In-Reply-To: Message from "Jerry E. Pournelle <POURNE@mit-mc>" of Fri 27 Jan 84 03:19:00-CST

        Do let's remember that ARPANET collected statistics are to be
used selectively and generally without attribution to the net. I'm not
sure where in the profit/persoanl gain spectrum BYTE delivery dates
fall, but this is the stuff of which Proxmireing types make their living
(a multimillion dollar DOD network was used to coordinate personal
magaine subscriptions....). Info-CPM is too nice a thing to have go away
just because we failed to keep the standard arpanet low public profile.
                -KM<
-------
27-Jan-84 11:23:15-MST,856;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:23:11-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 10:26 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  27 Jan 84 10:22 EST
Date: 26 Jan 1984 20:35-PST
Sender: ABN.ISCAMS@usc-isid
Subject:  Re:  Byte finally showed up
From: ABN.ISCAMS@usc-isid
To: ron@brl-vgr
Cc: young@uci-750a, ciaraldi@rochester, info-cpm@brl
Cc: info-micro@brl, jpm@bnl, jpm@brl
Message-ID: <[USC-ISID]26-Jan-84 20:35:01.ABN.ISCAMS>
In-Reply-To: The message of     Thu, 26 Jan 84 14:15:57 EST from     Ron Natalie <ron@brl-vgr>

Now look, Ron -- don't go starting that up!  I've purged my poor overflowed
directory of 50 bloody Byte messages already.  So leave February alone already!

(Jeeeez!)

David Kirschbaum
Toad Hall
27-Jan-84 11:24:25-MST,2663;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:24:13-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 10:49 EST
Received: From Brl-Voc.ARPA by BRL via smtp;  27 Jan 84 10:41 EST
Date:     Fri, 27 Jan 84 10:24:44 EST
From:     "Ferd Brundick (LTTB)" <fsbrn@brl-voc>
To:       Herb Lin <LIN@mit-mc>
cc:       cpmlist@brl-vgr, STEVEH@mit-mc, info-cpm@brl
Subject:  Re:  multiple FTP gets from SIMTEL20 for CPM stuff..

Haaah,

Our local implementation of ftp doesn't have the 'script' or 'xfile'
commands, so we have to use re-directed input.  I grabbed all the
cpmug catalog files (1 per directory) by building a file containing
the following commands:
    verbose
    tenex
    get "micro:<cpmug.vol001>catalog" catalog.001
    get "micro:<cpmug.vol002>catalog" catalog.002
    ...  (more of the same)
    bye

I actually built this file with a shell script that used the 'while' construct:
    i=1
    while test $i -lt 10
    do
        echo "get \"micro:<cpmug.vol00$i>catalog\" catalog.00$i" >>ftp.commands
        i=`expr $i + 1`
    done
(The sequence \" protects the double-quote)

Once you have built the ftp command file, you enter the following command:
    ftp simtel20 <ftp.commands
If you are transferring a large number of files, you may want to run the job
in the background by putting a '&' after the command line:
    ftp simtel20 <ftp.commands &

If the files require post-processing to remove the ITS header or convert CR/LF
to LF (for UN*X compatibility) put the ftp line in a second shell script:
    ftp simtel20 <ftp.commands
    for i in list_of_files
    do
        behead $i temp
        del.cr temp $i.fixed
    done

While this method requires a lot of work initially, it is much easier than
manually typing lots of 'get' commands.  The super-ftp file transfer program
that Dave Towson mentioned will (someday) be an interactive C version of the
method outlined above (but not this weekend -- I'm patching WordStar).

If you have any questions, problems, or suggestions, feel free to write to
me:  <fsbrn@brl-voc>

By the way, an easy way to transfer a small number of files is to put part
of the name in a Special Function key (I do this on an hp terminal):
    get "micro:<cpmug.vol
which saves some of the typing (and I don't forget what I'm supposed to use).

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>

27-Jan-84 13:14:56-MST,992;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 13:14:52-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  27 Jan 84 14:42 EST
Date: Fri 27 Jan 84 12:42:04-MST
From: Keith Petersen <KPETERSEN@SIMTEL20.ARPA>
Subject: Using MDM720 with CDOS
To: INFO-CPM@BRL-VGR.ARPA


Date:     Mon, 27 Jan 84
From:     Keith Petersen, W8SDZ
To:       All
Subject:  Using MDM720 with Cromemco CDOS

CDOS users: Get M7CD-1.ASM, the overlay for Cromemco systems.

After you overlay MDM720.COM using DEBUG, patch the following
locations to NOPs (binary zeros): 2AB7, 2AB8, 2AB9, 2ABA.

This will disable the CP/M disk stat call function 1Fh which is
not implemented in the current version of CDOS.  The MDM720 DIR
function will then work, but will show 0k left on the disk.
That's livable, and certainly better than before when CDOS gave
an error message and jumped out of MDM720 to return to the system.
--Keith
-------
27-Jan-84 16:07:51-MST,970;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 16:07:44-MST
Received: From Mit-Multics.ARPA by BRL-VGR via smtp;  27 Jan 84 17:39 EST
Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MULTICS.ARPA TCP; 27-Jan-1984 17:33:33-est
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 27-Jan-1984 17:27:15-est
Date:  Fri, 27 Jan 84 15:25 MST
From:  Dreschel%his-phoenix-multics.arpa@BRL-VGR.ARPA
Subject:  problem with OMIKRON
To:  info-cpm@BRL-VGR.ARPA
Message-ID:  <840127222540.948423@HIS-PHOENIX-MULTICS.ARPA>

Help! I mailed an order to Omikron Systems in Berkely, CA in the
second week of Oct. 83 and have still not received the hardware
and software. They have not responded to my last two letters either.
I paid by money order so I am beginning to fear I'll never see my
money again. Any suggestions would be greatly appreciated.Z(

                    Bill Dreschel
27-Jan-84 16:48:00-MST,953;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 16:47:53-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  27 Jan 84 18:22 EST
Date:     Fri, 27 Jan 84 18:12:20 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Dreschel%his-phoenix-multics.arpa@brl-vgr.arpa
cc:       info-cpm@brl-vgr.arpa
Subject:  Re:  problem with OMIKRON

Bill - Here is some information concerning your problem.  Good luck!

     The following is from the February issue of "80 Micro".  It is from their
"80 Alert" column on page 14.

"80 Micro has received complaints from readers that Omikron Systems 
(1127 Hearst St., Berkeley, CA 94702) has not filled orders or issued refunds.
Omikron informed 80 Micro that it was issuing refunds and expected to be 
shipping within a few weeks.  Customers who contacted 80 Micro had received
refund checks by press time."


Dave
towson@amsaa


27-Jan-84 18:37:11-MST,639;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 18:37:07-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 20:14 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  27 Jan 84 20:12 EST
Date: Fri 27 Jan 84 17:15:59-PST
From: William Pearson <PEARSON@SUMEX-AIM.ARPA>
Subject: Simtel-20 directories
To: info-cpm@BRL.ARPA



There seem to be a lot more files available on Simtel-20 than I am aware
of, e.g. UNIX.CPM and CPMUG.?.  I wonder if there is a more complete
list of what is available in MICRO: than CPM.CRCLST?

Bill Pearson


-------
27-Jan-84 21:35:18-MST,1553;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 21:35:13-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  27 Jan 84 23:11 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  27 Jan 84 23:04 EST
Date: 27 January 1984 23:05 EST
From: Stephen C. Hill <STEVEH@mit-mc>
Subject:  Making WordStar 3.3 come up faster
To: INFO-CPM@mit-mc
cc: STEVEH@mit-mc

    I have significantly increased the speed with which
WordStar 3.3 comes up.

    First of all, I had to get rid of the silly MicroPro
advertisements.  This was accomplished by using a combination
of DDT and ZDASM.  I traced the beginning of the program,
breakpointing just after each CALL instruction until I
discovered the guilty module.  Eventually, I narrowed it down
to where I replaced the instruction located at 3CEB with a jump
relative of 3A, which branched around all of the craziness that
MicroPro put up.

    That just left getting rid of the long delay loops that
they had left in there.  I could have used the same trick of
branching around some code, but the faster fix was to change
the three delay-count bytes located at 2B0 through 2B2.  I have
changed them all to 0, and have noticed no problems of leaving
things on the screen with the Molecular MT-100 terminals.  Give
it a try with larger numbers, if your terminals have any
problems, although they probably won't.

    Someone will probably tell me that there is an option int
the WINSTALL menu, but I sure couldn't find it. 

30-Jan-84 08:35:33-MST,1178;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 08:35:28-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  30 Jan 84 8:52 EST
Date: Sun, 29 Jan 1984  13:27 EST
Message-ID: <SJOBRG.11987522481.BABYL@MIT-OZ>
From: SJOBRG%MIT-OZ@MIT-MC.ARPA
To:   Info-Cpm@BRL-VGR.ARPA
Subject: Heath/Zenith Z-100 extended video
Cc:   sjobrg%MIT-OZ@MIT-MC.ARPA
In-reply-to: Msg of 14 Dec 1983  20:57-EST from Keith Petersen <w8sdz at brl>

The November 1983 issue of Microsystems magazine carries a review of the
Zenith Z-100 computer system.  The review states:

    The video board allows an alternate display format, which
    could be used to provide an interlaced display of 640 by
    525 pixels, but no information is provided on specific
    programming for that purpose.  (p. 100)

I have often lamented the fact that many video displays (such as the IBM
PC) only go up to 400 lines vertically when 480 would have permitted a
square aspect ratio (so important when dealing with digitized images as
I often do).  Does anyone have any information about this capability in
the Zenith machine?  Thanks.

30-Jan-84 09:07:37-MST,669;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 09:07:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 9:01 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  29 Jan 84 2:12 EST
Date: Sat 28 Jan 84 23:15:51-PST
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: Cat program for CPM 1.4
To: info-cpm@BRL.ARPA

  The NCATxx programs show the amount of free space on each
diskette with CPM 2.x but will not with CPM 1.4 because
DSKFRE must bee disabled (BDOS function
not available).
  Does anyone know of a cataloging program
that does what NCAT does for CPM 1.4?
-------
30-Jan-84 14:29:44-MST,1244;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:29:39-MST
Received: From Usc-Isid.ARPA by BRL-VGR via smtp;  30 Jan 84 8:58 EST
Date: 28 Jan 1984 23:22-PST
Sender: ABN.ISCAMS@usc-isid
Subject: IOBYTE on the Decision I
From: ABN.ISCAMS@usc-isid
To: INFO-CPM@brl-vgr
Cc: ABN.ISCAMS@usc-isid, INFO-MICRO@brl-vgr
Message-ID: <[USC-ISID]28-Jan-84 23:22:48.ABN.ISCAMS>

I think I have succeeded in implementing the IOBYTE on my Decision I.
I adapted the original North Star segments of Morrow's CBIOS&, and it
seems to work just fine (though haven't figured out many applications
for the additional capability yet).

Gotta fire up GENERIC KERMIT and try out the IOBYTE configuration to see
if that application works.

Any Decision I owners out there interested -- yell, and I'll work up the
patches in a document.  (But give me a few days.)

Still no luck on adapting the BIOS to run soft sector 5 1/4" floppy drives
(as opposed to the N* hard sector ones it was written for) - but I'm told
I'll need a newer (Ver. 2.5) DJ/DMA PROM and am inquiring about that through
my vendor now.  I'll keep you posted.

David Kirschbaum
Toad Hall
(ABN.ISCAMS@USC-ISID)
30-Jan-84 14:29:52-MST,1014;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:29:48-MST
Received: From Usc-Isid.ARPA by BRL-VGR via smtp;  30 Jan 84 8:58 EST
Date: 29 Jan 1984 18:33-PST
Sender: ABN.ISCAMS@usc-isid
Subject: IOBYTE on the Decision I
From: ABN.ISCAMS@usc-isid
To: INFO-CPM@brl-vgr
Cc: abn.iscams@usc-isid
Message-ID: <[USC-ISID]29-Jan-84 18:33:44.ABN.ISCAMS>

Yep -- my IOBYTE implementation works (couldn't be absolutely sure at 0400
when things were kind of stupid out).

Now, gentlesirs and madams -- what do I do with it?  Neat, I guess to list
a document to printer or screen, but I could do that anyway!

What neat, wonderful, otherwise impractical/impossible tricks can I do with
an IOBYTE that I couldn't do before?

(The Toad, for some reason, doesn't seem surprised that such strange
redirection is occurring in its innards - computers can be so complacent
sometimes!)

Regards,
David Kirschbaum
Toad Hall
(ABN.ISCAMS@USC-ISID)
30-Jan-84 14:30:03-MST,972;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:29:58-MST
Received: From Sri-Nic.ARPA by BRL-VGR via smtp;  30 Jan 84 9:04 EST
Received: from USC-ECLB by SRI-NIC with TCP; Sun 29 Jan 84 20:29:41-PST
Date: 29 January 1984  20:29-PST (Sunday)
Sender: TLI@usc-eclb
From: Tony Li <Tli@usc-eclb>
To:   Info-Cpm@brl-vgr
Subject: Re: CP/M 68K
Reply-to: Tli@usc-eclb
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168


Hi,

There is another release of CP/M-68K on the way.  It includes some
fixes to the C compiler and the OS.  I have played with it in-house.
From what I have heard on the net, it may take quite a while to get
distributed.

As far as DRI compilers go, there seems to be a wide variation in
quality.  Some are very good, and some are very poor.  The release
that I know of for the in-house C compiler falls into the latter
category.  Sigh.

Cheers,
Tony ;-)
30-Jan-84 14:30:31-MST,1378;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:30:22-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 9:02 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  29 Jan 84 5:09 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 29 Jan 84 2:11-PST
Date: 4 Feb 84 7:37:18-EST (Sat)
To: info-cpm@brl
From: hplabs!hao!seismo!philabs!rdin!perl@ucb-vax
Subject: Re: Function 37 - drive door open
Article-I.D.: rdin.347

Willard Korfhage suggests that the index hole sensor can be used
as a drive door sensor since the disk stops spinning when you
open the door.  This would not work on most 5.25" drives since
the disk times out and stops spinning whenever it is not being
accessed.  (nice try)

As a point of interest to this discussion, Hewlett-Packard used
to make a machine called the HP250.  Although it didn't run CP/M
or anything like it, it had a kind of 8" floppy drive I have
never seen elsewhere.  The drive door could be locked by software
so the user could be physically prevented from removing the disk!
Also, when you closed the door, you could hear the machine accessing
the disk; probably reading the directory.  (Note that the HP250
was a multi-tasking multi-user system.)

Robert Perlberg
Resource Dynamics Inc.
New York
philabs!rdin!rdin2!perl
30-Jan-84 14:31:05-MST,1385;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:30:57-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 10:59 EST
Received: From Stl-Host1.ARPA by BRL via smtp;  29 Jan 84 11:09 EST
Date: 29 Jan 1984  10:10 CST (Sun)
Message-ID: <WANCHO.11987497510.BABYL@STL-HOST1>
From: WANCHO@stl-host1
To:   "Stephen C. Hill" <STEVEH@mit-mc>
Cc:   INFO-CPM@brl
Subject: Making WordStar 3.3 come up faster
In-reply-to: Msg of 27 Jan 1984  22:05-CST from Stephen C. Hill <STEVEH at mit-mc>

Steve,

Several years ago someone else also came up with the idea of changing
the delay bytes to zero, as well as a couple of other items.  He since
discovered that zero was NOT correct, although it appears to work.
The correct value for each of those delay bytes should be one.

About a year ago, I received verbal permission to publish his patch
file, stripped of identification, but I forgot to actually do so until
you brought the subject up.  I will upload the file to the SIMTEL20
tomorrow.  Look for PATCHWS.ASM in MICRO:<CPM.WSTAR>.  It applies to
WS 3.0, and may have to be slightly modified for 3.3.

The remainder of the patch concerns itself with intercepting the
console status calls, and making the actual calls every 16th.  This
significantly improves the screen updates!

--Frank
30-Jan-84 14:31:19-MST,1477;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:31:11-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 10:59 EST
Received: From Stl-Host1.ARPA by BRL via smtp;  29 Jan 84 11:35 EST
Date: 29 Jan 1984  10:35 CST (Sun)
Message-ID: <WANCHO.11987502112.BABYL@STL-HOST1>
From: WANCHO@stl-host1
To:   William Pearson <PEARSON@SUMEX-AIM.ARPA>
Cc:   INFO-CPM@brl
Subject: Simtel-20 directories
In-reply-to: Msg of 27 Jan 1984  19:15-CST from William Pearson <PEARSON at SUMEX-AIM.ARPA>

There are four major directories in MICRO: accessible via FTP.  Each
has its own dir.CRCLST file in the major directory.  They are:

MICRO:<CPM.*>        - all the archives formerly on MC, updated
MICRO:<CPMUG.VOLnnn> - nnn = 001-054, 078-090
MICRO:<SIGM.VOLnnn>  - nnn = 000-145
MICRO:<UNIX.*>       - a fledgling repository of UNIX-related files

BTW, contributions of public domain software are always actively
solicited.  Submissions to MICRO:<CPM.*> are coordinated by Keith
Petersen, W8SDZ@SIMTEL20.  Submissions to MICRO:<UNIX.*> are
coordinated by Rick Conn, RCONN@SIMTEL20 (or rconn@BRL).

Incidentally, MICRO: is the name of a nearly full RP06.  We are
anticipating additional large collections of UNIX software to be
available soon.  At that point, we expect another site may be online,
and the UNIX files moved to their new home.  Look for another
announcement.

--Frank
30-Jan-84 14:31:32-MST,936;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:31:28-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 11:00 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  29 Jan 84 11:45 EST
Date: 28 Jan 1984 22:52-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re: Heath/Zenith Z100 Newsletter
From: ABN.ISCAMS@usc-isid
To: hplabs!hao!seismo!ut-sally!ut-ngp!knutson@ucb-vax
Cc: info-cpm@brl
Message-ID: <[USC-ISID]28-Jan-84 22:52:11.ABN.ISCAMS>
In-Reply-To: The message of 19 Jan 84 19:51:18-PST (Thu) from hplabs!hao!seismo!ut-sally!ut-ngp!knutson@ucb-vax

Jim (et al),

I too am quite interested in the INFO-HZ100 Digest.  I saw a single first
edition come over the net weeks ago from a student (?) at some university
(Clarkson?), but nary a peep since.  Please inform if anyone has a pointer.

David Kirschbaum
Toad Hall
(ABN.ISCAMS@USC-ISID)
30-Jan-84 14:31:44-MST,1303;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:31:37-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 11:01 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  29 Jan 84 11:45 EST
Date: 28 Jan 1984 22:58-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re: Zenith 100
From: ABN.ISCAMS@usc-isid
To: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax
Cc: info-cpm@brl
Message-ID: <[USC-ISID]28-Jan-84 22:58:17.ABN.ISCAMS>
In-Reply-To: The message of 19 Jan 84 18:48:41-PST (Thu) from hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax

Ref your question on the correctness of the Z100's S100 bus --
I closely queried a sales team recently here at Ft Bragg (including the area
manager or some such from Charlotte).  They confirm (for what it's worth)
a true S100 bus, but could give absolutely no information or recommendations
on what (if anything) else would run on it beside Zenith boards.  I'm
watching this myself, since I'd like to stay with S100 to maintain
compatibility/backup with my Toad (a Morrow Decision I).  No word yet from
the USAF or USN - not enough of them out there yet, I guess, or not enough
adventuresome people to stick alien boards in a Govt-owned machine!

David Kirschbaum
Toad Hall
30-Jan-84 14:32:46-MST,616;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:32:42-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 11:20 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  30 Jan 84 5:31 EST
Date: 30 January 1984 05:31 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Zenith 100
To: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax
cc: info-cpm@brl
In-reply-to: Msg of 19 Jan 84 18:48:41-PST (Thu) from hplabs!hao!seismo!ut-sally!ut-ngp!garey at ucb-vax

buy it quick  that's a good machine, and for a Kaypro price...
grab it

30-Jan-84 14:34:16-MST,3902;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:34:03-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 11:33 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  30 Jan 84 9:57 EST
Date: Mon, 30 Jan 84 09:50 EST
From: Phillips.henr@PARC-MAXC.ARPA
Subject: Apple Modem Program
To: "Ferd Brundick (LTTB)" <fsbrn@brl-voc.ARPA>
cc: Phillips.henr@PARC-MAXC.ARPA, ABN.ISCAMS@usc-isid.ARPA, info-cpm@brl.ARPA

Is this program available in this area ??  I am in desperate need !
(or better yet, can I send you a disc ??)  I am looking for a way
to send CP/M files between Apple Super Serial and an 820-II.
Thanks for any help you can offer !!

Mark
---------------------------

Received: from BRL-VGR.ARPA by PARC-MAXC.ARPA; 20 JAN 84 09:41:50 PST
Redistributed: XeroxInfo-CPM^.wbst
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  20 Jan 84 10:03 EST
Received: From Brl-Voc.ARPA by BRL via smtp;  20 Jan 84 12:05 EST
Date: Fri, 20 Jan 84 11:56:24 EST
From: "Ferd Brundick (LTTB)" <fsbrn@brl-voc.ARPA>
To: ABN.ISCAMS@usc-isid.ARPA
cc: info-cpm@brl.ARPA
Subject:  Re:  "?Public domain version of MODEM in Apple Pascal?"

Hi,

Since Toad Hall has also expressed interest in an Pascal Modem7, I am
sending a copy of my original reply to the list at large.

- - - - - - - - - -

There <IS> a modem3 program written in Apple (SCUD) Pascal.  The files
are on simtel20 in MICRO:<CPM.PASCAL> and the names are given below.
I've never used the program because I don't own an Apple, but I do have
the MODEM3.PAS file if you can't get it from simtel20 (I can get and send
you the other 2 files if you need them).  Anyway, below is the header
info from the main file.

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>

PROGRAM modem;
      {Written by Jack M. Wierda  Chicago Illinois
      This program is in the public domain.

      LANGUAGE: UCSD Pascal
      FILES:    MODEM3.PAS -- main program
                MDM3-Z80IO.Z80 -- serial line interface for Z80
                MDM3-8080IO.Z80 -- serial line interface for Intel 8080

      This program is basically a re-write in PASCAL of Ward Christensen's
Modem Program which was distributed in CP/M User's Group Volume 25. Identical
and compatible options are provided to allow this program to work directly
with Ward's program running under CP/M. One difference is that when sending
files the PASCAL or CP/M transfer mode must be selected. The PASCAL mode
transfers files between two systems running PASCAL, while the CP/M mode is
used when the receiving system is running CP/M. Basically the CP/M mode
provides the linefeeds required to make a PASCAL file compatible with CP/M.
When CP/M files are received they contain linefeeds, these can be deleted
using the editor to make the file compatible with PASCAL. CP/M files may also
contain tabs which the PASCAL editor does not expand.
      External assembly language routines are used to read the status, and read
or write the keyboard and modem ports. These routines are available as
separate files for the 8080 and Z80 processors. The port and flag definitions,
and the timing constant for the one second delay should be changed as required
for your particular hardware.
      The program has been tested with text files only, and may not work
correctly for code or other types of files.
      The PDP-10 mode transfers PASCAL files to a DEC SYSTEM-10 computer.}

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
------------------------------------------------------------

------------------------------------------------------------

30-Jan-84 14:36:33-MST,1577;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:36:18-MST
Received: From Gunter-Adam.ARPA by BRL-VGR via smtp;  30 Jan 84 12:16 EST
Date: 30 Jan 1984 1116-CST
Subject: Z-100 graphics..
From: Doug <HUNEYCUTT@gunter-adam>
To: Info-CPM@brl-vgr


The Z-100 dedicates 3 64K banks to RGB video display RAM.  The 6845 CRT
controller is highly programmable.  You can program the beast to display
other than the standard 225 scan lines, but you have to go into interlace
mode to do it.  Zenith's new catalog has a slow-decay color monitor for
use with interlace applications (the standard B&G and RGB monitors flicker
noticeably when interlaced mode is used).

  A point to make is that the Z-100 is always in graphics mode.  All displays
are software (or firmware) controlled.  When programmed with the standard
boot-up parameters, each character consists of 9 bytes (one per scan line).
You <can> program the controller to use up to 16 scan lines without changing
too much, which gives 400 lines/screen (25 text lines).  To go higher than
400 lines, you need to take into account the ROM address mapping scheme used
by the Z-100 to simplify screen memory accesses.

  One of the engineers said that, with 64K RAMs installed, you could technically
go higher than 800 scan lines per screen.  Don't know exactly how you'd do
that, but no matter...no screen could handle that density.  HUG has some 
demo software (SARTC, etc) that demonstrates the interlace/high density modes.

Doug
-------
30-Jan-84 14:37:01-MST,769;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:36:56-MST
Received: From Hi-Multics.ARPA by BRL-VGR via smtp;  27 Jan 84 23:53 EST
Date:  27 January 1984 21:49 mst
From:  Bill Vaughan <VaughanW@hi-multics>
Subject:  cpmug/sigm file format on simtel20
To:  info-cpm@brl-vgr
cc:  VaughanW@hi-multics

Can anyone tell me something about the format of the CPMUG and
SIGM files on Simtel20?  When I FTP them I get a binary format
that I haven't been able to decipher, even those that should be in
ASCII such as catalogs and .DOC files.   Are they compressed or
something?  Perhaps someone on a Multics somewhere has already
figured out how to FTP these things comprehensibly.

			Bill Vaughan
30-Jan-84 14:37:15-MST,681;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:37:12-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 0:24 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  28 Jan 84 0:15 EST
Date: Sat 28 Jan 84 00:13:31-EST
From: DVW.KJB%MIT-OZ@MIT-MC.ARPA
Subject: MDM715/6/7/8/9.... overlay for Apple
To: info-cpm@BRL.ARPA

I would like to know if there's anyone out there that would be interested
in getting the Apple overlay for MDM7xx to work for the DC Hayes Micromodem.
I'd hack it to work myself, but I'm relatively new to CP/M and 8080/Z-80
programming.   Thanks!
    - Kevin

-------

30-Jan-84 14:38:29-MST,2034;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:38:21-MST
Received: From Amsaa.ARPA by BRL-VGR via smtp;  28 Jan 84 8:43 EST
Date:     Sat, 28 Jan 84 8:31:22 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Bill Vaughan <VaughanW@hi-multics>
cc:       info-cpm@brl-vgr, VaughanW@hi-multics
Subject:  Re:  cpmug/sigm file format on simtel20

Bill - ALL sigm and cpmug archive files on Simtel20 are stored in ITS binary
format, which uses four bytes per 36-bit word (that includes four junk-zeros 
per word).  If you use plain binary mode in FTP, you will get the 36-bit words
as-is, which will comeout looking pretty strange on an 8-bit system.  To get
the files moved correctly in bytes, use TENEX mode if your FTP has it (just
type "tenex" at the FTP prompt, and if the program doesn't complain, you're
in).  Otherwise, try typing "type L8" to notify the sender that the local 
user (you) wants bytes not 36-bit words.  (Can someone tell me whether this is
necessary for a TOPS-to-TOPS transfer?)  After setting tenex or type L8 mode,
then do your gets.  Due to the ITS format, you will have four ITS "header
bytes" hanging on the front of the file you receive.  These can be stripped
using a utility on the receiving machine (e.g., DD on UNIX), or you can go
ahead and move the files to your CP/M machine and use Keith Petersen's ITSCVT,
which can be found in "micro:<cpm.hex>itscvt.hex" on Simtel20.  That is an 
ASCII file.  If you are using a UNIX system (which expects lines in ASCII files
to be ended with only a line feed) you will find that after you move an ASCII 
file to the CP/M machine, you may have the CRLF's that were already in the file
(and were not changed to LF-only by the receiving FTP because this was a 
binary transfer) have been changed to CRCRLF.  (You may be able to turn this 
off.)  If you do have this problem, the CP/M ED command mf^L^Z-3cd2c will 
remove the extra CR's.


Dave
towson@amsaa

30-Jan-84 14:41:43-MST,1016;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:41:39-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 11:38 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  28 Jan 84 11:32 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 6:43-PST
Date: 19 Jan 84 19:51:18-PST (Thu)
To: info-cpm@brl
From: hplabs!hao!seismo!ut-sally!ut-ngp!knutson@ucb-vax
Subject: Re: Heath/Zenith Z100 Newsletter
Article-I.D.: ut-ngp.243
In-Reply-To: Article <118@5941ux.UUCP>

Sorry for sending this to everyone but our mailer has problems.

Where did you see that there was an Info-HZ100 Digest?  I have searched
all over ARPANET for it and can't find it.  Also, if you have a copy of
the Newsletter or have a net address for David Gubbins, please send them
to me.  I am extremely interested in any H/Z100 info you have.

-- 
Jim Knutson
ARPA: knutson@ut-ngp
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
30-Jan-84 14:44:43-MST,959;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:44:38-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 11:38 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  28 Jan 84 11:31 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 6:41-PST
Date: 19 Jan 84 18:48:41-PST (Thu)
To: info-cpm@brl
From: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax
Subject: Zenith 100
Article-I.D.: ut-ngp.242

	There is a deal here at Univ. of Texas to get a Zenith 100
with 2 drives, 128K ram etc for $1975.00.  This seems like a great
deal but I need to know if the S-100 bus in that machine is really
standard.  For example will standard Compupro boards fit?  Could
I pop in a hard disk, more memory, and a 68K board (say from compu-
pro) in the near future and off I go to Unix land?  Or does the
thing require special things from Heath/Zenith?

ut-ngp)
30-Jan-84 14:45:02-MST,806;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:44:59-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 11:38 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  28 Jan 84 11:31 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 6:40-PST
Date: 19 Jan 84 18:41:12-PST (Thu)
To: info-cpm@brl
From: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax
Subject: SIMTEL CP/M ARCHIVES
Article-I.D.: ut-ngp.241

	A few months ago someone posted a message on how to ftp files
from SIMTEL CP/M archives.  The message was quite long and included
examples.  I have managed to misplace this message and can't find it
locally.  Could someone send me a copy?     

		Thanks,

			Jim Garey  (garey@ut-ngp)
30-Jan-84 14:45:14-MST,2235;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:45:08-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 12:12 EST
Date:     Sat, 28 Jan 84 12:04:02 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Kaypro 10 undocumented features

The following is a file relayed from the Sysop Clearinghouse RCPM.
---
					Jan 5, 1984

                   UNDOCUMENTED VIDEO FEATURES
                        FOR THE KAYPRO 10

                          By Ron Mozer

The KAYPRO 10 has several undocumented features available to the
user which are undocumented in any of the Kaypro manuals.  These
features include a 25'th line and the ability to save and recall
the cursor possition.  If you look at the owners manual for the
computer you will find a section which describes character attri-
butes commands.  These commands allow inverse video, blinking,
reduced intensity, etc.  This is documentation on two more of the
commands.

The table of commands can be updated to the following:

			To Turn ON:		To Turn OFF:

Inverse Video		ESC,"B0"		ESC,"C0"
Reduced Intensity	ESC,"B1"		ESC,"C1"
Blinking		ESC,"B2"		ESC,"C2"
Underlining		ESC,"B3"		ESC,"C3"
Cursor			ESC,"B4"		ESC,"C4"

Save Cursor Pos.	ESC,"B6"     To Recall  ESC,"C6" <--- New
25'th line 		ESC,"B7"		ESC,"C7" <--- New

As you can see there is an obvious gap for the "B5" - "C5" attri-
butes.  I have not found out what these do and would be interested
in hearing from anybody that does via the Mesilla Valley RCP/M
(505)522-8856.

What follows is a sample MBASIC program which demostrates these
features:

10 REM THIS PROGRAM WILL DEMONSTRATE THE 25'TH LINE AND OTHER FEATURES
20 REM OF THE KAYPRO 10.
50 REM
110 PRINT CHR$(27);"B6" : REM SAVE CURSOR POSITION
120 PRINT CHR$(27);"B7" : REM ENABLE 25'TH LINE
130 PRINT CHR$(27);"=8 "; : REM MOVE CURSOR TO 25'TH LINE
140 PRINT "THIS IS THE 25'TH LINE" : REM SHOW USER WE CAN DO IT!
150 PRINT CHR$(27);"C6" : REM RECALL CURSOR POSSITION
160 REM WHEN YOUR DONE WITH THE 25'TH LINE IT MAY BE DISABLED
170 REM WITH THE FOLLOWING
180 PRINT CHR$(27);"C7": REM DISABLE 25'TH LINE
30-Jan-84 14:45:39-MST,6933;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:45:20-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 12:12 EST
Date:     Sat, 28 Jan 84 12:05:21 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  MDM720 now available

MDM720, the latest version in the MODEM7 series, is now available 
on SIMTEL20 in the MICRO:<CPM.MODEM7> directory (and temporarily 
on MIT-MC in the FJW; directory).  The file names are:

 SIMTEL20       MIT-MC
MDM720.ASM    MDM720 ASM
MDM720.COM    MDM720 COM  (in ITS-binary format on both hosts)
MDM720.HEX    MDM720 HEX
MDM720.MSG    MDM720 MSG
M7NM-5.ASM    M7NM   5ASM (phone number overlay - see note below)

NOTE: This program when assembled is 69 sectors long.  Use this figure 
when merging the appropriate overlay file for your computer via DDT, 
etc.  (Most of the overlays were written when MDM7xx.COM was only 66 
sectors and the example included in each says to store 66 sectors.)  
For MDM720 use: SAVE 69 MDM720.COM.

NOTE: If using the phone number overlay to change the phone library 
numbers, be sure to use: M7NM-5.ASM (Previous versions of M7NM will not 
work with this new version, as the file transfer buffer is now optional 
length, nominally set for 4k and there is an option to show/not show 
the both the decimal and HEX record count.)

Most users will not need the lengthy (154k) source code.  Just get 
MDM720.COM and then check one of the associated overlay programs to 
obtain the overlay for your particular computer.  Merge that with 
MDM720.COM according to the instructions near the start of the overlay 
file, using DDT.COM, etc.  (See above note relative to saving 69 
sectors.  STAT.COM would then show 138 records for 18k.)

CHANGES FOR MDM720
------------------
     Changed the printer routine - a number of people had problems with 
the printer working properly.  It now works correctly for several who 
previously had problems.  Increased the stack depth.  Now have the 
ability to select "SHOWHEX" via DDT with a byte two ahead of NUMBLIB.  
This requires using M7NM-5.ASM if you want to change the telephone 
number library.

	0CFEH  -  HEXSHOW 00 = do not show hex record count
			  FF = show both hex and decimal count
	0CFFH  -  SAVSIZ  20 = 4k file transfer buffer size
			  40 = 8k file transfer buffer size
			  80 = 16k file transfer buffer size
	0D00H  -  NUMBLIB (start of telephone number library)
					- Irv Hoff

CHANGES FOR MDM719
------------------
     Fixed error in GETACK routine which prevented the robust improve-
ment (added in MDM716) from working.  Changed ACKNAK to NO so default
will require valid NAK rather than non-ACK.  This is part of the robust
improvements, not because of any special ArpaNet requirement.  Changed
SHOWHEX to true for distribution version so users would have HEX and
DECIMAL reporting while transferring files (most users have told me
they prefer to see both).  Changed PMMI dialing pulse default to 10pps
which most exchanges will accept.  (This can be set to other pulse rates
in the user overlay.)			- Keith Petersen, W8SDZ

CHANGES FOR MDM718
------------------
     Code added to the auto-dial routine for the new Anchor 300/1200
modem which are selling at discount houses for $270 or so.  Computer now
beeps continuously anytime a connection is made to attract the operator's
attention.  Made the file transfer buffer length separate from that of
the ASCII capture buffer (which remains 16k, one file-extent).  Although
the file transfer buffer has been 16k for well over a year, some of the
newer floppy disk systems are quite slow and timeout errors could occur.
The file transfer buffer size is set by default to 4k (32 records, 20H).
It can be set at assembly time if using the entire MDM720.ASM file, or
can be set in a few seconds with DDT by changing byte 0CFFH.  The number
library is now fully automatic to insure it always starts on a new page
(such as 0D00H) regardless how much the auto-dial section is altered.
Now responds to either "single digit" result codes (some Hayes Smartmodem
users leave SW2 set that way) as well as the normal "verbose" result
codes.
 
     To change the file transfer buffer size via DDT, change byte 0CFFH:

		10   (hex)   =   16 records   =   2k
		20   (hex)   =   32 records   =   4k
		40   (hex)   =   64 records   =   8K
		60   (hex)   =   96 records   =  12k
		80   (hex)   =  128 records   =  16k

     (then SAVE 69 MDM.COM, etc.)

CHANGES FOR MDM717
------------------	
     MDM717 allows characters with parity bit set to be properly handled
during propagation overruns after an X-off.  This occurs during a "save
to disk" after the disk buffer fills.  (This problem was noticed on Com-
puserve which sends some characters with the parity bit set.)

     The disk buffer size was restored to 16k.  This is the length of
"one file extent".  Even slow floppy disks can store 16k in a reason-
able amount of time.  This should remain 16k for distribution copies of
the source code although it can be easily changed to suit the individual
user's own preference.  (It could even be lengthened to 32k if you like
fewer disk operations.	This would make the printer buffer proportion-
ally smaller but most printers are so fast the buffer is rarely filled
in any case.)

     Fixed a stack problem introduced in v716 in the "V" flag routine to
allow the user to show ASCII characters on the CRT during a file trans-
fer.

     Fixed the "L" Logon feature so it should be consistent.  At times
it would run away without waiting for the echo characters, thus not cor-
-rectly displaying the Logon message.

     Restored the ACKNAK feature developed for the exclusive use of the
ARPANET networking group.  When set normal ("YES") it resends a disk re-
cord after any NON-ACK character is received.  This has been the normal
configuration for all RCPM systems using the XMODEM file transfer pro-
gram.  When set "NO" for ARPANET use, it resends a record only after a
NAK has been received.	Other characters are ignored.  Some systems will
resend a NAK after a 10-second TIMEOUT.  This slows things considerably,
which allows the main frame time to recover if busy.  This tends to run
the phone bill higher for RCPM use, but is necessary for ARPANET to pre-
vent aborting the file transfer too quickly if the main frame is busy.
If a normal TIMEOUT sequence does attempt to abort the transfer with the
ACKNAK equate set to NO, it will ask if you want to try again or abort.
(RCPM systems would have already timed completely out with 10 consecutive
errors, making the question worthless and misleading.  ARPANET does not
have a similar feature, and the user can manually force the transfer to
continue.)		- Irv Hoff

--end--
30-Jan-84 14:45:51-MST,1401;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:45:45-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 12:13 EST
Date:     Sat, 28 Jan 84 12:08:51 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  MDM720 and the Racal-Vadic modem

Relayed from the Sysop Clearinghouse RCPM.  M720RV.ASM is available
on SIMTEL20 in the MICRO:<CPM.MODEM7> directory.
---

Date:  1/25/84
From:  Dave Mabry
To:    All
Re:    M720RV.ASM

I have just uploaded M720RV.ASM.  It is a modification of the
file M7RV-1.ASM from M7OVLx.LBR.

It is an overlay that supports the Racal-Vadic PA212 "smart"
modem similar to the way the Hayes is supported by MDM720.
The previous version (M7RV-1.ASM) was set for MDM712 I think
and would not work with ANY other version.  I have done
some significant modifications that should make it easier
to use with specific hardware, but it is still VERY specific
to the version of MDM7xx it works with.  Hence, the MDM7xx
full version number in its name (M720RV.ASM).  It needs
to be overlayed AFTER overlaying the user's normal M7XX-1
file.  Read the comments inside for more details, but it
Seems to work very nicely with the Vadic PA212 modem.
Please remove the original (M7RV-1.ASM) from the overlay
library and replace it with this one.  Thanks.
30-Jan-84 14:46:48-MST,1490;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:46:42-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 12:23 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  28 Jan 84 12:17 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 9:11-PST
Date: 18 Jan 84 18:51:55-PST (Wed)
To: info-cpm@brl
From:  ihnp4!alberta!ubc-vision!uw-beaver!tektronix!tekred!billr@ucb-vax
Subject: mdm71x - missing feature/bug
Article-I.D.: tekred.23

There exists what I think is an important oversight in the
design of the Smartmodem dialing code for MDM712 (and I
assume, later versions).  That is, if you select Pulse dialing
in the configuration file, it will not let you use alternate
dialing (i.e. SPRINT, MCI).  The other item that goes along
with this is that the dialing routine will not let you switch
from pulse to tone dialing in mid-stream.

What I want to do is this:

	555-5555,,,,,T999,777
	^      ^     ^  ^ ^ ^
	--------     ---- ---
	pulse dial  tone dial
	  for        for
    switchboard     access code and extension

As it stands now, I have to use Terminal mode and type the
long string in each time.  I wish one of the maintainers of
MDM7xx would fix this problem and send me a copy (I don't
have the source or I'd fix it myself; I discovered this
Tracing with DDT - ugh!).

	-Bill Randle
	tektronix!tekred!billr		UUCP
	billr.tektronix@rand-relay	ARPA
30-Jan-84 14:46:59-MST,599;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:46:55-MST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  28 Jan 84 12:31 EST
Date: 28 January 1984 12:32 EST
From: Keith Petersen <W8SDZ@mit-mc>
Subject: MDM719.ASM->MDM720.ASM DIF file available
To: Info-Cpm@brl-vgr

Anyone who already has MDM719.ASM and wants MDM720.ASM can get a DIF
file (for use with SSED2 on CP/M) which will create MDM720.ASM. The
file is available on SIMTEL20 as MICRO:<CPM.MODEM7>M719720.DIF and
temporarily on MIT-MC as FJW;719720 DIF
--Keith

30-Jan-84 14:47:19-MST,1609;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:47:12-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 12:55 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  28 Jan 84 12:49 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 9:40-PST
Date: 27 Jan 84 0:37:48-PST (Fri)
To: info-cpm@brl
From: hplabs!hao!seismo!uwvax!heurikon!jeff@ucb-vax
Subject: Re: DRI C Compiler Woes
Article-I.D.: heurikon.185
In-Reply-To: Article <15918@sri-arpa.UUCP>

Your report was on CP/M-86 'C' compiler bugs and DRI's failure
to fix them in the second release.  I don't think DRI concentrates
too much on their compilers.  We were a beta test site for CP/M-68K.
The O/S worked fine, but wow(!) were there ever a lot of 'C' compiler
bugs.  They've acknowledged all of them and pointed out that they
are relying on their supplier to fix them, since they didn't write
the thing.  (I'll tell you who did if you ask, but not on the net.)

There's only been one release of CP/M-68K so far, and I'm waiting
to see if the bugs are fixed in the next release.  But, frankly,
I won't be too surprised it they aren't.

Fortunately, all of the bugs have work-arounds.  But I'm slightly
bald now from pulling hair, and I've gotten very good at reading
the cryptic *.s files produced by the compiler to find out what
the 68K is *really* doing.
-- 
/"""\	Jeffrey Mattox, Heurikon Corp, Madison, WI
|O.O|	{harpo, hao, philabs}!seismo!uwvax!heurikon!jeff  (news & mail)
\_=_/				     ihnp4!heurikon!jeff  (mail)
30-Jan-84 14:48:15-MST,1585;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:48:10-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  28 Jan 84 15:14 EST
Received: From Gunter-Adam.ARPA by BRL via smtp;  28 Jan 84 15:12 EST
Date: 28 Jan 1984 1412-CST
Subject: Z-100/IEEE-696 (S-100)
From: Doug <HUNEYCUTT@gunter-adam>
To: Info-CPM@brl
cc: Huneycutt@gunter-adam


The S-100 bus in the Z-100 is indeed IEEE-696 engineered.  The system supports
5 slots, one of which is taken by the floppy disk controller, another by the
Winchester controller (if you have one).  You can plop any IEEE-696 card into
the machine, with one noteable exception....(sigh)

  You see, even the motherboard of the Z-100 is broken into logical parts.
The memory circuitry is a 'logical' S-100 card, the video circuitry another,
and so on.  Accordig to the designer, you could DMA video pictures into the
display memory if you have a DMA device driver (which the floppy controller is
NOT)  

  PROBLE:  The CPU circuitry is configured as an IEEE-696 PERMANENT MASTER!!
This precludes the addition of a standard S-100 CPU card, as it will also want
to be a permanent master.  The Zenith folks are thinking about it.

(Note:  for those of you with a Z-100 already, look at the back.  There is a
        very long cut-out at the top (about the length of a standard S-100
        card).  Yup, they actually thought about extending the S-100 outside
        the main box.  Just think what your RFI sources could do with that!!)

Doug
-------
30-Jan-84 20:24:23-MST,918;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 20:24:19-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  30 Jan 84 21:48 EST
Date: 30 Jan 1984  19:49 MST (Mon)
Message-ID: <WANCHO.11987875908.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@simtel20>
To:   INFO-CPM@brl-vgr
cc:   INFO-MICRO@brl-vgr
Subject: TRS-80 II Parallel Printer Routines Wanted!

After trying all available versions of various modem programs, such as
MDM720, which claims to have printer buffering fixed, I've come to the
depressing conclusion that our ancient Lifeboat BIOS' LISTAT is broken
- i.e., returns always ready, and thus overruns.

So, I'm asking if anybody can spare a working LISTAT and LSTOUT
routine to let me drive the parallel printer directly, and I'll wedge
it into one of these programs.  CP/M or anyDOS routines welcome!

Thanks,
Frank
30-Jan-84 20:36:36-MST,648;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 20:36:28-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  30 Jan 84 21:53 EST
Date: 30 Jan 1984  17:41 MST (Mon)
Message-ID: <WANCHO.11987852742.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@simtel20>
To:   INFO-CPM@brl-vgr
Subject: RBBS4 (in BDS-C!) Available

A version of RBBS, written in BDS-C, is now available in
[SIMTEL20]MICRO:<CPM.RBBS4>.  Note that it requires BDS-C 1.50a due to
the use of the index function.  It has not been tested with any prior
version.

Bug reports, etc., directly to me.

--Frank
30-Jan-84 21:14:14-MST,932;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 21:14:01-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 22:55 EST
Received: From Rochester.ARPA by BRL via smtp;  30 Jan 84 22:53 EST
Received: by sen.rochester (3.327.3N) id AA06410; 30 Jan 84 22:53:08 EST (Mon)
Received: by cay.Rochester (3.327.3N+) id AA01196; 30 Jan 84 22:49:49 EST (Mon)
Message-Id: <8401310353.6410@sen.rochester>
Date: 30 Jan 84 22:53:08 EST (Mon)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re: DRI C Compiler Woes
To: hplabs!hao!seismo!uwvax!heurikon!jeff@ucb-vax.ARPA, info-cpm@brl.ARPA

Thanks for the info.
Did outsiders do the C compiler for both CP/M-68K and 86,
or do you only know for sure on the 68K?
So, who did it?
You can send to me privatley
as
"ciaraldi@rochester", or I can give you
US mail or phone if you want.

Mike Ciaraldi
31-Jan-84 08:10:05-MST,779;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:09:58-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  30 Jan 84 23:47 EST
Received: From Rochester.ARPA by BRL via smtp;  30 Jan 84 23:39 EST
Received: by sen.rochester (3.327.3N) id AA06805; 30 Jan 84 23:39:04 EST (Mon)
Received: by cay.Rochester (3.327.3N+) id AA01296; 30 Jan 84 23:35:46 EST (Mon)
Message-Id: <8401310439.6805@sen.rochester>
Date: 30 Jan 84 23:39:04 EST (Mon)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re: DRI C Compiler Woes
To: Mike Ciaraldi <ciaraldi@Rochester.ARPA>, 
    hplabs!hao!seismo!uwvax!heurikon!jeff@ucb-vax.ARPA, info-cpm@brl.ARPA

Whoops!
Preceding message was supposed to have been private.
31-Jan-84 08:10:51-MST,1781;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:10:22-MST
Received: From Sri-Nic.ARPA by BRL-VGR via smtp;  31 Jan 84 3:09 EST
Received: from USC-ECLB by SRI-NIC with TCP; Tue 31 Jan 84 00:09:15-PST
Date: 30 January 1984  23:24-PST (Monday)
Sender: TLI@usc-eclb
From: Tony Li <Tli@usc-eclb>
To:   Info-Cpm@brl-vgr
Subject: DRI 'C'.
Reply-to: Tli@usc-eclb
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168


Hi,

The 8086 version of the DRI 'C' compiler was done by Mike Lehman (of
Pascal-MT+) fame.  It is supposedly a fairly complete implementation.
I am very much not impressed with the code that it generates, however.
I have also had problems with this compiler under CCP/M.  If you
switch consoles while it's running, use some memory, and then it goes
to allocate some memory that isn't available, it turns off interrupts
and goes away.  This of course, may be a feature of the version of
CCP/M that I was using.  Also, I was using the Engr. Dept. release of
6-July-1983.  I don't know what that corresponds to in a retail
version, but I do know that it was significantly improved (!!!) over
the version that was available at the time of the product's
announcement.

The CP/M-68K compiler was done by an outside company.  It does have a
few bugs.  My favorite was the lack of flagging of an error when you
set up a data structure that doesn't sit on a longword boundary.  Got
bit by that several times.  All in all, I would say that it is a
fairly good compiler.  The code generation is not bad, and the error
messages are reasonable.  Having the four phases patched together by
an external SUBMIT file, though, is something of a drag. Sigh.

Cheers,
Tony ;-)
31-Jan-84 08:11:03-MST,603;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:10:58-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  31 Jan 84 3:13 EST
Received: From Mit-Multics.ARPA by BRL via smtp;  31 Jan 84 3:05 EST
Date:  Tue, 31 Jan 84 03:03 EST
From:  Schauble@MIT-MULTICS.ARPA
Subject:  Function 37 - drive door open
To:  info-cpm@BRL.ARPA
Message-ID:  <840131080333.111355@MIT-MULTICS.ARPA>

Program lockable doors on 8 inch drives are not that uncommon. My Qume
DT8's have them. Unfortunately, my disk controller doesn't know about it.
31-Jan-84 08:12:46-MST,1658;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:12:14-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  31 Jan 84 4:35 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  31 Jan 84 4:23 EST
Date: 31 January 1984 04:24 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject: help needed
To: INFO-CPM@mit-mc, INFO-MICRO@mit-mc

Back before the big ARPA split, I could download files to my
system with MITE, which sends XMODEM protocol (and could also do
PLINK and I guess a couple of others).

Now I get nothing, and it is a comprehensive drag since I have
to reset the machine to break the losing send, then find a free
TIP, then log back on to kill that failed job.  Sigh.

If there is anything a science fiction writer/columnist could do
in return, I would like a favor from o someone: from time to
time could download some of my files to 8" disk (SSSD IBM format
to be sure we don't get problems) and send by US Snail.  I will
gladly pay for the service, and perhaps an autographed book or
two would be useful as thanks?
	I do not really understand TIPS and su ch, and MITE
tells you NOTHING other than "T" for "timed out" or "R" for
retry; MModem gets the R's in quantity , Lmodem (which also used
to work for me)  gets 2 r's and a string of T's.  Neither seems
a very useful message.  Maybe my enthusiasm for MITe (because
when it's working it is really easy to use) is misplaced.

Anyway, I could use help, if theres anyone with time and
capability of downloading files.  This is insanity; there has to
be a way to do this, but I don't know it.
JEP

31-Jan-84 08:13:51-MST,1430;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:13:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  31 Jan 84 8:32 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  31 Jan 84 8:11 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 31 Jan 84 5:10-PST
Date: 30 Jan 84 6:40:32-PST (Mon)
To: info-cpm@brl
From: ihnp4!ihuxq!covert@ucb-vax
Subject: Needed:8088 x-assembler for cpm-80
Article-I.D.: ihuxq.562

I need a cross assembler for the Intel 8088 CPU which runs under
cpm-80. I have a small 8088 controller board which I bought at a
Hamfest. I would like to be able to write some small 8088 assembly 
language programs for it. I have a z-80 based cpm system with an eprom
programmer. If I could get a cross assembler that would generate Intel
HEX files then I could burn my own proms.

Can anyone out help me locate such at tool (BTW I need something in the
public domain or else inexpensive).

Also, has anyone ever heard of a version of basic called  TBASIC written
for the 8088?? I got an 8755 with TBASIC burned into it with the
controller.

Also, any ideas about a good assembly language programming book for the
8088??

Please mail your repsonses to me unless they are of interest to the net.

-- 
			Richard Covert
			BTL Indian Hills West, Room 1E-408
			...ihnp4!ihuxq!covert
			(312) 979-7488
			
31-Jan-84 08:14:16-MST,1094;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:14:10-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  31 Jan 84 8:59 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  31 Jan 84 8:46 EST
Date: Tue, 31 Jan 84 08:44 EST
From: Westfall.Henr@PARC-MAXC.ARPA
Subject: Re: Heath/Zenith Z100 Newsletter
In-reply-to: <[USC-ISID]28-Jan-84 22:52:11.ABN.ISCAMS>
To: ABN.ISCAMS@usc-isid.ARPA
cc: hplabs!hao!seismo!ut-sally!ut-ngp!knutson@ucb-vax.ARPA, info-cpm@brl.ARPA

I believe that the person that mentioned the info-hz100 digest was Dave
Gubbins (Gubbins@Radc-Tops20). Last time I checked, he was working for
Rome Air Development Center at Griffis AFB in Rome, NY. The school that
both he and I graduated was Clarkson College, who recently required all
incoming freshmen to purchase Z100 computers. I believe that they
currently have about 1600 machines on campus, and a computer networking
is being implemented to interconnect the whole lot of them.

Rob Westfall
Xerox Corp
Westfall.Henr@Parc-maxc


